return when desugaring to closures

[Maciej Stachowiak]

On Oct 16, 2008, at 7:01 PM, Brendan Eich wrote:

> On Oct 16, 2008, at 3:33 PM, Brendan Eich wrote:
>
>> On Oct 16, 2008, at 1:20 PM, Waldemar Horwat wrote:
>>
>>> I don't think you can come up with a consistent "shift" or  
>>> "greedy" notion.
>>
>> Funny, yacc has had one for decades, used to resolve dangling-else.
>
> Which ES1-3 also use:
>
> 12.5 The if Statement
> Syntax
> IfStatement :
>       if ( Expression ) Statement else Statement
>       if ( Expression ) Statement
> Each else for which the choice of associated if is ambiguous shall  
> be associated with the nearest possible if that would otherwise have  
> no corresponding else.
>
> The grammar is not enough in ES3 without let expressions. You need  
> at least this shift-reduce conflict resolution rule (I'm ignoring  
> ASI, / as division vs. regexp delimiter, etc.). Adding let  
> expressions does not add novel requirements for extra-grammatical  
> disambiguation rules.
>
> The ambiguity between blocks and object initialisers is another well- 
> known case, resolved by "negative lookahead":
>
> 12.4 Expression Statement
> Syntax
> ExpressionStatement :
>       [lookahead ∉ {{, function}] Expression ;

This one can be solved without negative lookahead, we have separate  
NoBF (no brace or function) and NoIn productions in our grammar to  
solve these without ambiguity:

Expr:
     AssignmentExpr
   | Expr ',' AssignmentExpr
;

ExprNoIn:
     AssignmentExprNoIn
   | ExprNoIn ',' AssignmentExprNoIn
;

ExprNoBF:
     AssignmentExprNoBF
   | ExprNoBF ',' AssignmentExpr
;

With the NoIn / NoBF variants propagated through the rest of the  
grammar if needed. Kind of brute force, but it does the job without  
ambiguity. JavaScriptCore's grammar runs through bison with no shift/ 
reduce or reduce/reduce conflicts.

I think it might be better to write the official ES3.1 grammar in this  
way, even though it is a little annoying and repetitive, so it can  
more readily be verified that the language grammar has no ambiguities  
by running through a parser-generator like yacc or bison or  
boost::spirit.

As to the else issue, I don't think that ambiguity can be avoided, but  
bison lets you solve that with %nonassoc, which is a sound  
disambiguation mechanism.

Regards,
Maciej

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.mozilla.org/pipermail/es-discuss/attachments/20081016/4ccb70d1/attachment.html