On Sun, 14 Jul 2002, Brent Dax wrote:
> Deborah Ariel Pickett:
> # My perl5 sensibilities tell me that that's likely to cause a
> # problem when I want to do something like this:
> #
> # $hashref = { function_returning_hash() };
> #
> # because I won't get the function's return values put into a
> # hash, because the stuff inside the { ... } isn't a list of
> # pairs. Instead I'll get a (reference to) a closure, not at
> # all the same thing.
You've got a point. There's an easy way to say "I want a sub":
my $sub = -> { ... }
But I can't think of a similarly punctuation-intensive way to say "I want
a hash." (someone please step in and correct me).
> # that this is being phased out for perl6 (the grammar backs that up).
I wouldn't take the grammar too seriously -- it's more or less one
person's interpretation of the Apocalypses, Exegeses, and recent mailing
list traffic.
> my HASH $hashref;
> my CODE $subref;
So if I have the above two declarations, and do this later:
$hashref = { ... };
$subref = { ... };
It does "the right thing"? This could work up to a point, but Perl can do
crazy things like this:
$foo ?? $hashref :: $subref = { ... };
and propagate context differently to different branches of the ternary
(try doing $x ? @y : $z = (2,3,4) sometime -- very cool!). And while we
could interpret the block differently on each branch, that seems a bit too
scary.
> (Alternatively, always parse it as a closure and afterwards run through
> the parse tree, checking all the closures and converting those that only
> contain pairs.)
Or use context to try and figure it out. Unfortunately, from the outside
I think either would just look like "a reference". Maybe if the compiler
could figure out that your function would return pairs, it could fix
things up so that turns into a hash-ref. But then you can get into
trouble with a function that returns pairs only in non-hash-ref
contexts...
/s
