Good examples. Now could you provide some to explain to me why it's
important to distinguish between '$', '@', '%', and '&'? I ask
because I've seen a lot of object-based code that has said stuff like
'$container{$key}';

Advertising

Well, $container{$key} is how you access elements of %container in
Perl5; in Perl6 that's %container{$key}. But in object-based P5 code,
you'd be much more likely to see $container->{$key}, where $container
contains a reference to a hash. I believe in P6 you could write that
either as $container.{$key}, $container{$key} (where the . is implied
since $container{$key} can't refer to %container anymore), or
%$container{$key}.
If I understand your point, however, it is that the availability of
references, which are scalars, has essentially removed the
scalar/array/hash/sub distinction, since you can store references to
any of those things in a $var. Further, in order to dereference such
references, you need something beyond the sigil anyway, which takes
its place as a type disambiguator.
You aren't the only person who feels this way; there was a proposal
back in the RFC process to remove sigils in favor of "everything is a
scalar, dereference as needed". I was in that camp myself. But Larry
rejected that proposal, defending the utility of sigils, and I have
been swayed by the arguments, which I'm not going to repeat because I
can't say it as well, but I do advise you to go read - it was either
Apoc1 or Apoc2, I think.
Anyway, one of the things I like about the Perl6 design is that it
essentially restores sigils to their pre-Perl5 importance via
automatic referencing and dereferencing according to context. This
effectively removes the "everything's a scalar anyway" argument since
you can toss references around without making everything a $var. (I
dunno how many times I have tried to declare and initialize a hash
with my %hash = { ... }, which initializes the hash to have a single
element whose key is the hash reference provided and whose value is
undef... but in P6 that does the right thing.)
--
Mark J. Reed <[EMAIL PROTECTED]>