Allen's lambda syntax proposal

[Brendan Eich]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20081218/23af94cc/attachment.html>