[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