On Wed, Apr 20, 2005 at 05:08:53PM +0200, Ingo Blechschmidt wrote:
: Hi,
:
: Autrijus Tang wrote:
: > %ret = map { $_ => uc $_ }, split "", $text;
: [...]
:
: I suppose my test is wrong.
:
: When I clicked on reply a moment ago, I wanted to propose to change the
: hash/code disambiguation rule, so that {...} is always parsed as Code
: if the body contains "$_" or "$^...".
:
: But as this change would break the following code, I think we should
: leave it as it now.
: my @AoH = map {
: my $hashref = { $^a => ... };
: do_something_with $hashref;
: $hashref;
: };
Hmm, what we have said in the past is that the proper way to disambiguate
that is to require an explicit "return" if you mean the closure, but that
doesn't actually work unless there's an explicit "sub". I suppose the
rightest answer at this point is:
%ret = map { ($_ => uc $_) }, split "", $text;
since the => is no longer the top-level operator, but the parens are, if
you believe in parens as an operator and not just a grouper. Or
%ret = map { $_ => uc $_; }, split "", $text;
should presumably also work. That may look like an arbitrary amount
of lookahead, but I tried to define the hash/closure rule in terms of
a semantic analysis rule rather than a syntax rule, such that it's
always parsed as a closure, but at some point in semantic analysis
you can look at the AST and see that the top-level operator is =>,
and throw an implicit "new Hash: do" on the front of the closure,
or whatever operator it is that evaluates a closure for its pairs
and builds a hash from it.
I'd really like to save the overloading of {...} if we can DWTM in most
cases and at least produce decent errors in the other cases. We can
certainly produce a decent "Maybe you meant..." diagnostic on the
map thingy, even if it defaults counterintuitively in that case.
Larry
