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
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
