Removal of NoIn grammar productions and for-loop parsing

Brendan Eich brendan at mozilla.com
Mon Sep 2 09:45:57 PDT 2013


Erik Arvidsson wrote:
>
> How is this different than destructuring assignment? We need a cover 
> grammar in this case too.
>

The toy (reduced) grammar I showed is ambiguous, just as ES3's grammar 
would be if you were to remove the NoIn productions.

Destructuring is ironically already covered (cover-grammar sense) by 
ES3's grammar already, without ambiguity (allowing the lookahead 
restriction by which an expression statement cannot start with '{' of 
course). LeftHandSideExpression indirectly produces ArrayLiteral and 
ObjectLiteral. Those are ruled out as legal LHS forms only by PutValue.

By now it should be clear that while a semantic restriction (static or 
not) can make an error of one case or another, it cannot disambiguate a 
grammar. Parsing comes first and must be unambiguous to be sound. See

https://mail.mozilla.org/pipermail/es-discuss/2008-October/007883.html 
(overlong line-paragraphs)
http://www.mail-archive.com/es-discuss@mozilla.org/msg01008.html (ads, 
but wrapped lines)

"""

This is why ambiguous grammars are bad and unsuitable for our spec.  In an
unambiguous grammar, if you find a series of production expansions that matches
a source program, then you know that those are the expansions that will be
taken.  In an ambiguous grammar, you also need to prove the negative:  no
*other* expansion can match that source program and shadow your expansions.
Proving the negative causes trouble because a language extension could turn the
mismatch into a match and because sometimes, as in the above case, you expected
some other part of the grammar to shadow your expansions but it didn't.

     Waldemar

"""

After this thread, we agreed following vigorous debate to stick with 
LR(1) (sans ASI) for ECMA-262. I don't think we should go back on this 
decision.

/be


More information about the es-discuss mailing list