At 7:38 PM -0700 4/27/06, Larry Wall wrote:
On Thu, Apr 27, 2006 at 01:10:05PM -0700, Darren Duncan wrote:
: 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.
Okay, avoiding 'Raw' due to overload is fine.
However, I would argue that the word 'Blob' is no
better because, taken at its original meaning of
"Binary Large OBject", we are implying that it is
only intended for storing large things. But I
intended for it to be used for small things too,
such as 1 or 20 or 400 byte chunks of data.
A better name is one that doesn't imply size.
Perhaps just 'Binary', if that isn't also
overloaded. Or perhaps 'BitStr' or 'Str::Bit'.
Though Binary sounds better, being a single word.
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.
How about data that 'pack' or 'unpack' work with?
That's often defined in terms of strings of bits.
And what about encrypted data? Likewise, often
as strings of bits.
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.
What you say about better typing is true;
however, if we want to have a system where one
can easily define their own custom immutable
types, which can be composed partly or entirely
of chunks of binary data, then such a Binary type
would be a good foundation on which to build them.
Fundamentally, I see it being valuable that users
can make any kind of custom data type that is
immutable, so that users or implementers of those
custom types can reap many or all of the same
benefits as those of immutable built-ins.
: 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.
Thanks for the confirmation. So that would mean
that Set.pm in its current state doesn't
implement a mathematical set, since its objects
are mutable.
The value of a set member is its existence, which is constantly true
for the set members.
Yes, I agree.
But why do you assume that a Hash has to store
a real value?
Because in my experience that is what people have
always done with them, unless examples using
'undef' don't count as such.
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.
Yes, that solution works for me.
I had been using constant values of 1 in my
coding before when I just used a hash like a set.
But the syntax of %foo{'bar'} = 1 still looked
like there were 2 things being associated, 'bar'
and '1'.
On the other hand, if these values indicate how
many times their key is in the hash, then a value
which is always 1 would happen to be correct.
But I won't dwell on this particular matter any longer.
: 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?
If we were still going the route of naming a
mutable set container, then 'Bag' is
inappropriate because the term is commonly used
to mean multi-set, an unordered sequence of
things where each thing can occur multiple times.
If we wanted an actual mutable Bag, the ordinary
Hash would suffice in the same way it does for a
mutable Set, but that each hash value is a number
that is >= 1 rather than just 1; the hash value
would count the number of occurances of the
multi-set member.
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.
If people actually do commonly use hashes as
mutable sets, then it probably would be useful to
have those operators for consistency and
interchangeability with the immutable sets;
however, I won't push for them at this time.
I'm just not sure every type we think of really needs a new name...
Larry
Yes. In fact I appreciate the fact that Perl 6
has the variety of types that it does, which
mostly or fully cover the needs of any common
problem domain, and can be overloaded for a
variety of similar uses, though people may use
different names for them depending what
problem-solving domain they come from.
Thank you. -- Darren Duncan
