return when desugaring to closures

[Waldemar Horwat]

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