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