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