On Dec 17, 2008, at 1:42 PM, Lex Spoon wrote:
I can share some history for the => form. It's disconcerting that
everyone associates it with C#, because they are open about copying
the syntax from Scala.
It's for Ecma solidarity -- we are indirectly boosting another Ecma
standard (C# is ECMA-334, IIRC), albeit at the expense of Scala :-P.
Ok, enough of that (we really do not try to align Ecma language
standards, which include Eiffel!). Thanks for the precedent correction.
On this list, the => form has so far been dismissed due to parsing
concerns. If that's the only reason, let me try and allay that worry
and put that horse back in the race. Scala also has a comma operator,
but it still manages to parse the => syntax. They way it does it is
to initially parse an expression and then, if it sees a =>,
reinterpret what it has seen so far as a parameter list. It's an
unusual parsing strategy, but it works well and the issue is
localized.
I called the => syntax "no-go" for JS in
https://mail.mozilla.org/pipermail/es-discuss/2008-December/008352.html
cites two general arguments.
First, parsing top-down and then revising the AST based on right
context is do-able -- but the "This can get ugly" remark is meant to
suggest that it's costly compared to choosing a grammar that avoids
the ambiguity.
On the plus side, destructuring in JS1.7, proposed for Harmony to
broad agreement, requires similar revision:
[p, q] = [q, p];
swaps p and q, but it starts like
[p, q];
(and of course could be nested anywhere an assignment expression could
occur).
Let's say we can overcome this objection, by selling the benefit to
the users over the cost to implementors (and users, in minor code
footprint; slippery slope hazard here, otherwise it's not a big cost).
I'm not confident this assumption will hold in committee -- need to
get Waldemar's reaction, at least -- but for now let's just say :-).
The second argument is that the issue may not be localized, especially
in light of automatic semicolon insertion. A counter-example adapted
from the "The trouble with ambiguous grammars" thread:
a => a ? f : x++
(0);
A function expression in JS today is a primary expression, e.g.
var f = function (a) { return a ? f : x++; }
(0);
so lambda users might expect the same precedence.
If the grammar is something like this:
AssignmentExpression:
...
| identifier '=>' AssignmentExpression
| '(' parameters ')' '=>' AssignmentExpression
(which AFAICT from web C# 3.0 grammars is what C# does) then we may be
ok. We'd need to check carefully.
Mono C# seems to have to bend over backwards to parse C# lambdas:
http://tirania.org/blog/archive/2007/Feb-15.html
but I don't see why a bottom-up parser can't decide quite late,
compared to a top-down parser, that it has a lambda parameter list and
not a parenthesized expression.
Perhaps we dismissed the => syntax too quickly, but we need a checked
bottom-up grammar. It's not enough to assert locality, unfortunately,
given the existing grammar and the complexity of automatic semicolon
insertion.
/be
_______________________________________________
Es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
