return when desugaring to closures
Waldemar Horwat
waldemar at google.com
Fri Oct 17 11:05:17 PDT 2008
Brendan Eich wrote:
> On Oct 16, 2008, at 7:04 PM, Waldemar Horwat wrote:
>
>> The parser is required to backtrack until it either finds an expansion
>> of the grammar that doesn't generate a syntax error or until it
>> discovers that they all do. You can choose to make additional syntax
>> errors as per chapter 16, but that does not relieve you of the
>> backtracking requirement.
>
> You're right that a bottom up parser will have a reduce-reduce conflict.
> For a top-down parser, it's not an issue.
>
>
>>>> Other examples: What does the following do?
>>>>
>>>> for (a = let (b = c) b in d) ...
>>>
>>> SyntaxError because no ; after first expression in for (;;) loop head.
>>
>> It can't be a SyntaxError. It's a perfectly valid for-in statement.
>
> Is this a perfectly valid for-in statement?
>
> for (a = b in c);
>
> Not according to ES3's grammar. An assignment expression is not valid on
> the left of the for-in's "in":
>
> /IterationStatement /*:*
> * ...*
> * for ( */LeftHandSideExpression /*in */Expression /*) */Statement/
> * for ( var */VariableDeclarationNoIn /*in */Expression /*)
> */Statement/
>
> LeftHandSideExpression does not produce an unparenthesized
> AssignmentExpression, and if you parenthesize then PutValue will throw
> on the non-Reference result of the assignment, the ReferenceError at
> runtime which again can become SyntaxError at compile time.
I accidentally took out the "var" in editing the message. It should have been
for (var a = ...)
Waldemar
More information about the Es-discuss
mailing list