Rod Adams writes:
> So I'm interested in hearing what pushes Arrays and Hashes over the
> edge for needing their own container and sigil, whereas Junctions/Sets
> do not.
Nothing. In fact, arrays and hashes aren't atomic or fundamental in any
respect, and the main thing that keeps them there is history.
And in fact, one of the big questions that's always in the back of my
mind (that I'm not searching for an answer to, but I'm always observing
for one) is: what do @ and % mean these days?
They have syntactical semantics:
sub foo ([EMAIL PROTECTED]) {
say @_.elems;
}
my @a = (1,2,3,4,5);
my $a = @a;
foo(@a); # 5
foo($a); # 1
Hashes do too, particularly in rules.
But what are some nice, abstract concepts that these could represent.
One that I've been thinking of is:
* @something is necessarily ordered: there is a well-defined "first element"
* %something is necessarily a set: adding something twice is always
redundant
Or something like that. I've noticed in my recent programming which has
been heavily algorithmic that sets are ubiquitous. % would still mean
hash by default, but hash would mean a "set of pairs".
Correspondingly, @ would mean array by default, but you could certainly
put a linked list in there.
The biggest problem (perhaps) with these abstractions is that
subscripting--their most common operation--is not well-defined.
Presumably most of these containers would define reasonable
subscripters, but if you ask for an array in your parameter list, you
may not even be able to subscript it.
So I don't think these are quite right. Also, rules refer to the
"value" of a hash for a partcular key, and that's not well-defined for
sets either.
Maybe now is the time to figure out what they *do* mean.
Luke
