<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Sep 6, 2012, at 10:19 PM, Joseph Spencer wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div>Would it not be beneficial to bring Annex A into greater conformity with<br>the rest of the spec at this point?  <br><br>Such changes seem relatively safe (to a noobie that is ;), as any code<br>produced moving forward by devs would still parse just fine under older<br>implementations that allowed for the unwanted syntax.  It seems that<br>doing so would also bring the ecosystem of implementations into greater<br>alignment moving forward.<br><br></div></blockquote><div><br></div><div>Annex A is just a informative summary of the normative BNF that is scattered through-out the rest of the document, so I think what you are really suggesting that w try to express more of the static semantics using the normative grammar.  For the ES6 spec. I'm actually going in a different direction which is more algorithmic specification of the static semantic restrictions on syntactically valid programs.  Many of these restrictions concern non-local feature interactions that are difficult or impossible to express purely using a non-attributed BNF.  If you haven't already, you should take a look at the ES6 draft <a href="http://wiki.ecmascript.org/doku.php?id=harmony:specification_drafts">http://wiki.ecmascript.org/doku.php?id=harmony:specification_drafts</a> </div><div><br></div><div>Just this morning, I wrote static semantic rules that cover the Postfix and PrefixExpression (and other assignment contexts) that you had noted.</div><div><br></div><div>Allen</div><div><br></div><div><br></div></div></body></html>