[no longer sent to perl6-internals because it's not relevant there]
I see a problem . . whether the problem's with me or the grammar, that's
for you people to decide.
Do I read this part of the grammar correctly?
> sv_literal: /(?:\d+(?:\.\d+)?|\.\d+)(?:[Ee]-?\d+)?/
> | '{' <commit> hv_seq '}' <----
> | '[' <commit> av_seq(?) ']'
> | <perl_quotelike>
>
> hv_seq: <leftop: pair ',' pair> /,?/
>
> term: '<' <commit> expr(?) '>'
> | subscriptable <commit> subscript(s?)
> | /$CONTEXT/o <commit> term
> | sv_literal <----
> | class
> | closure <----
A "term" can be either a scalar literal ("sv_literal") (which might be a
hash reference literal), or a closure (which might be a block).
Both of those could be written "{ stuff }", for various values of stuff,
but it looks like the current disambiguation rule is "if it's nothing
but a sequence of "pair"s, then it's a hash ref, otherwise it's a
closure.
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.
Of course, in perl5, the requirement that "sub" prefix any
closure-as-a-term nicely disambiguates that, but I understand that this
is being phased out for perl6 (the grammar backs that up).
How does perl6 distinguish between:
$hashref = { function_returning_hash() }; # call sub, get hash ref
and
$subref = { function_returning_hash() }; # make closure, don't call sub yet
?
(I hope the answer isn't "white space" . . )
[Hi, I'm new around here, so I'll give you the three-line introduction.
I teach Perl at Monash Uni, my office is in the same corridor as
Damian's, and I like cats, chocolate, and curry. (Not all at once.) ]
--
Debbie Pickett http://www.csse.monash.edu.au/~debbiep [EMAIL PROTECTED]
Ambivalent? Well, yes and no. - button slogan
