On 5/14/07, Jonathan Lang <[EMAIL PROTECTED]> wrote:
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}';


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

Reply via email to