Perl 6 built-in types
Darren Duncan
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
Larry Wall
: A couple of questions and suggestions about Perl 6 built-in data
: 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
Darren Duncan
>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.
Mark A. Biggar
> 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.
Please don't use bag as that is usually mathematically defined to be a
multi-set that can contain multiple copies of any given element. In
perl that would be a hash of Ints.
I'm not sure that immutable make any sense as a concept separate from
constant. A truly immutable object can't even be initialized, it has to
be born ex-nilo already with a value.
I think that only values (like 1, "ABC" and a set constant like
(1|2|5|9)) are immutable. So, we should just stick with variable and
constant (assigned once doesn't change afterwards) containers and not
use the term immutable at all.
Luke Palmer
> 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.
It seems like a hash whose values are the unit type. Does Perl have a
unit type? I suppose if it doesn't, we could define one:
subtype Unit of Int where 1;
(Assuming that "where" groks whatever "when" does).
Then your mutable set is:
my Hash of Unit $set;
Luke
Larry Wall
: It seems like a hash whose values are the unit type. Does Perl have a
: unit type? I suppose if it doesn't, we could define one:
:
: subtype Unit of Int where 1;
:
: (Assuming that "where" groks whatever "when" does).
:
: Then your mutable set is:
:
: my Hash of Unit $set;
Hmm, well, if values are just single-element subsets, then:
my %set of 1;
my 1 %set;
Larry
Darren Duncan
>I'm not sure that immutable make any sense as a concept separate from
>constant. A truly immutable object can't even be initialized, it has to
>be born ex-nilo already with a value.
Well, that depends on your philosophy.
I would argue that, philosophically, all values that can possibly
exist in the universal set have already existed and will continue to
exist eternally. By definition, a 'value' is both unique and
immutable. A value does not to be born in any sense because it is
eternal. Moreover, every 'value' is of a type, where that type is
defined as a subset of the universal set; a type can have values that
are arbitrarily complex or large, and less complex values have no
more claim to being a valid value than a more complex one.
While every value is unique, each one can have multiple appearances,
and for the sake of discussion, each appearance is the content of a
container, whether that container is updateable/mutable or
constant/immutable; each container is also of a type and can only
hold an appearance of a value of its type. Moreover, every container
always holds a value of its type at all times.
For example, there is only one value that is the number 42. If you
have a number variable containing 42, and you then update that
variable to contain the number 45 instead, you have not changed the
value 42 into a 45, but rather replaced its appearance in the
variable with an appearance of 45.
A related matter is that two things are considered equal if and only
if they are in fact two appearances of the *same* value.
So that's how things are conceptually, as I see it.
In some sense, I suppose this all sounds like quantum physics.
Now, our implementations of these concepts in a computer, regardless
of how we phrase it with syntax, all involve containers that are
some-how addressable; at some point in time, each is given an
appearance of a value, then depending on whether we declare the
container to be immutable/constant/non-updateable or
mutable/variable/updateable, it can possibly be made to hold an
appearance of a different value. An object is a container and it is
reasonable on a per-class basis that objects of that class can be
updateable or not.
Long story shortened, if we consider the point in time where an
"immutable" object's constructor returns as being when the object is
born, then we have no problem. Any type of object is thereby
immutable if it can not be changed after its constructor returns.
>So, we should just stick with variable and
>constant (assigned once doesn't change afterwards) containers and not
>use the term immutable at all.
I may be fine with this idea if we want to do it. But in the
mean-time, I will probably consider "immutable" and "mutable" to be
synoymous with "constant" and "variable".
>I think that only values (like 1, "ABC" and a set constant like
>(1|2|5|9)) are immutable.
Why stop there. I would argue that it should be possible to have a
type of any level of complexity that is declared immutable, such that
an object of that type isn't changed after its constructor finishes.
Denying this possibility on some arbitrary basis like with your list
makes as much sense as taking several things larger than a bit and
saying that some are atomic while others aren't.
-- Darren Duncan
TSa
Darren Duncan wrote:
> Long story shortened, if we consider the point in time where an
> "immutable" object's constructor returns as being when the object is
> born, then we have no problem. Any type of object is thereby immutable
> if it can not be changed after its constructor returns.
My lines of thinking about programs run along yours with values
existing eternally. But I think of the constructor of a constant
not as building the object in the first place *but* as making it
part of the current program. I imagine a conceptual membrane in
type space that encloses the program and shrinks and grows while
it is running. Mutability says something about the membrane's
changeability *not* about the value. This inside/outside metapher
is very strong. A mutable object is an aggregate of changing pieces
of the membrane in a fixed membrane frame of program real estate.
After understanding values as above, I just want to add that
the type of objects makes statements about all possible values
of its class. The runtime component of the type system enforces
all contstraints placed on values of the type while the program
attempts to modify the membrane to catch the values into it
or some such :)
In yet another view an object conceptually is a One Junction
over all possible values. At any given time in a program flow
the program space representing the object has a well defined
value. If it matches the intents of the programmer remains to
be seen!
--
TSa
And presumeably also
my %set of true;
my true %set;
But the real question is: "Does the storage optimization
fall out naturally or does it need explicit instanciation
of a generic hash container for the unit type?"
--