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.

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 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.

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().

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.

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.

Thank you. -- Darren Duncan

Reply via email to