return when desugaring to closures

Maciej Stachowiak mjs at
Fri Oct 17 18:52:05 PDT 2008

On Oct 17, 2008, at 11:17 AM, Waldemar Horwat wrote:

> Maciej Stachowiak wrote:
>> 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.
> It can.  I have a machine-validated ES3 (and ES4 from earlier  
> proposals) grammar that contains no ambiguities and no handwaving.   
> The if-else rule is handled by having a marker on Statement  
> productions just like there is a NoIn marker on Expression  
> productions.  See:
> I need a grammar with no ambiguities to do things like verify that  
> semicolon insertion works and that the / regexp-vs-division  
> resolution is always uniquely resolvable in favor of one or the  
> other:  you don't ever want a parser state which combines rules that  
> have division with rules that have a regexp in the same spot because  
> the lookahead depends on how you lex the /-token.

In that case I would definitely prefer to see the official spec have  
an unambiguous grammar.

(Your grammar still does include the  [lookahead∉{function, {}]  
construct which can be handled in an analogous way to NoIn.)


More information about the Es-discuss mailing list