return when desugaring to closures

Waldemar Horwat waldemar at google.com
Thu Oct 16 13:20:07 PDT 2008


Brendan Eich wrote:
> On Oct 16, 2008, at 11:38 AM, Waldemar Horwat wrote:
> 
>> Brendan Eich wrote:
>>> That's not a valid grammar.
> 
> It is unambiguous. How do you define "valid"?
> 
>>>  You can't have an AssignmentExpression terminating a 
>>> PrimaryExpression.  It leads to trouble such as:
>>
>> let a = b + c
>>
>> being interpreted as both:
>>
>> (let a = b) + c
> 
> No, it clearly parses as:
> 
>> let a = (b + c)
> 
> and we've shipped this for several releases, and it sees use -- it has 
> not been problematic. Parenthesize if you mean (let a = b) + 1.
> 
> Same goes for expression closures. Bottom up parsers will shift, top 
> down will consume greedily.

Huh?  There is notion of shifting or consuming greedily in ES3.  The ES3 grammar is unambiguous.

I don't think you can come up with a consistent "shift" or "greedy" notion.  The one you may be thinking of will happily accept code such as

let (a = 5) x + y.foo = 2;

yet the Firefox code gives a syntax error for it despite it being parsable by your "grammar".

> So what's the real problem?

I said it already.  The problem is that you don't have a valid grammar.  This one is invalid, so the code of the Firefox implementation is effectively the specification, and it's hard to reason about that.

Other examples:  What does the following do?

for (a = let (b = c) b in d) ...
vs.
for (a = let (b = c) b in d;;) ...
vs.
for (a = let (b = c) b in d in d) ...

    Waldemar


More information about the Es-discuss mailing list