On Thu, Apr 27, 2006 at 01:10:05PM -0700, Darren Duncan wrote:
: A couple of questions and suggestions about Perl 6 built-in data
: types, following a look at the newest S06 (
: http://svn.perl.org/perl6/doc/trunk/design/syn/S06.pod ) ...
:
: 1. There doesn't seem to be an immutable bit-string type, so unless
: I read something wrong, I propose adding one.
:
: Since all built-in types have one-word names, I suggest 'Raw', which
: doesn't currently seem to be in use.
That word is too overloaded, I think. Blob maybe.
: Unlike the immutable Str type, which is specifically defined to
: contain 'characters' (in the Unicode reportoire) or immutable bit or
: numeric types that hold a single bit or a single number respectively,
: the immutable Raw type would hold other kinds of data which isn't
: conceptually either character based or a number. Or more to the
: point, it would store data whose internal representation we don't
: want to know about for our purposes, or that is best stored as a bit
: string, such as perhaps a graphic or sound.
I don't actually see much use for immutable random chunks of memory that
wouldn't just about as well be served by a readonly buf. It's not like
two sounds much care if they have the same identity. And most random
chunks of bits should probably be typed better than that anyway or you'll
end up comparing your graphic to your sound.
: I do not see this need being served by any of Str or Buf or Array of
: Bit or Seq or anything like that. I see there being as much validity
: for such a Raw type as I described as the Str type, which holds
: multiple characters, rather than us just having a Char type that
: holds one character and being expected to use a Buf or Array of Char
: or Seq type to represent a string of them.
That paragraph did not make any sense to me.
: 2. While I grant that the module says it is going to be further
: updated, can I get a confirmation whether Pugs' ext/Set/lib/Set.pm is
: meant to implement the built-in Set type referred to in S06?
:
: If that is so, then they are currently out of sync such that S06 says
: a Set is an immutable type but Set.pm has public mutator methods like
: insert() and remove().
Mathematical sets are immutable.
: I propose that either the mutator methods be removed from Set.pm, or
: that there be 2 distinct types, one which is an immutable Set, and a
: similar type that is mutable, and that has a different name.
:
: Note that the mutable Hash type doesn't fill the role of a mutable
: set per se, because each distinct key has an associated value, but a
: set member doesn't have an associated value.
The value of a set member is its existence, which is constantly true
for the set members. But why do you assume that a Hash has to store
a real value?
: If such a new type is created, it could potentially be named
: MutableSet, though that would break the pattern of built-in types
: having one-word names, but I haven't thought of any alternatives so
: far.
How about Bag, a set container? Alternately what we really want is
just a Hash where the type of the value is defined as 1, so it need
not be stored at all. Then most of the syntax for it just falls out
of Hash syntax, unless you like writing $x ∈ $bag instead of $bag{$x}.
Presumably we could make both work.
I'm just not sure every type we think of really needs a new name...
Larry
