return when desugaring to closures

Maciej Stachowiak mjs at
Thu Oct 16 19:29:56 PDT 2008

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

   | ExprNoIn ',' AssignmentExprNoIn

   | 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  

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.


-------------- next part --------------
An HTML attachment was scrubbed...

More information about the Es-discuss mailing list