<HTML><BODY style="word-wrap: break-word; -khtml-nbsp-mode: space; -khtml-line-break: after-white-space; "><DIV><DIV>On Aug 22, 2007, at 2:17 PM, rasmus ekman wrote:</DIV><BR class="Apple-interchange-newline"><BLOCKQUOTE type="cite"><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">Just an arbitrary newbie question...</DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">I note that the updated UnaryExpression BNF<SPAN class="Apple-converted-space"> </SPAN></DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">codifies part of the behaviour of ES-262 implementations:</DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; min-height: 14px; "><BR></DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">UnaryExpression -&gt;</DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><SPAN class="Apple-tab-span" style="white-space:pre">        </SPAN>PostfixExpression</DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><SPAN class="Apple-tab-span" style="white-space:pre">        </SPAN>| delete PostfixExpression</DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><SPAN class="Apple-tab-span" style="white-space:pre">        </SPAN>| void UnaryExpression</DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><SPAN class="Apple-tab-span" style="white-space:pre">        </SPAN>| typeof UnaryExpression</DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><SPAN class="Apple-tab-span" style="white-space:pre">        </SPAN>| ++ PostfixExpression</DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><SPAN class="Apple-tab-span" style="white-space:pre">        </SPAN>| -- PostfixExpression</DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><SPAN class="Apple-tab-span" style="white-space:pre">        </SPAN>| + UnaryExpression</DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><SPAN class="Apple-tab-span" style="white-space:pre">        </SPAN>| - UnaryExpression</DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">(etc)</DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; min-height: 14px; "><BR></DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">So ++++a is ruled out at syntax level, and -++a is legal while ++-a isn't.</DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">This matches (part of) behaviour of current implementations.</DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; min-height: 14px; "><BR></DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">But is ++a++ going to become legal?</DIV></BLOCKQUOTE><DIV><BR class="khtml-block-placeholder"></DIV>Never, provided ++a cannot result in a magic native object of some kind (which could be an lvalue). See ECMA-262 Edition 3, Chapter 16:</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><FONT class="Apple-style-span" face="Arial" size="2"><SPAN class="Apple-style-span" style="font-size: 10px;">An implementation may treat any instance of the following kinds of runtime errors as a syntax error and therefore report it early:</SPAN></FONT></DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><FONT class="Apple-style-span" face="Arial" size="2"><SPAN class="Apple-style-span" style="font-size: 10px;">• Improper uses of </SPAN></FONT><FONT class="Apple-style-span" face="Arial" size="2"><SPAN class="Apple-style-span" style="font-size: 10px;"><B>return</B></SPAN></FONT><FONT class="Apple-style-span" face="Arial" size="2"><SPAN class="Apple-style-span" style="font-size: 10px;">, </SPAN></FONT><FONT class="Apple-style-span" face="Arial" size="2"><SPAN class="Apple-style-span" style="font-size: 10px;"><B>break</B></SPAN></FONT><FONT class="Apple-style-span" face="Arial" size="2"><SPAN class="Apple-style-span" style="font-size: 10px;">, and </SPAN></FONT><FONT class="Apple-style-span" face="Arial" size="2"><SPAN class="Apple-style-span" style="font-size: 10px;"><B>continue</B></SPAN></FONT><FONT class="Apple-style-span" face="Arial" size="2"><SPAN class="Apple-style-span" style="font-size: 10px;">.</SPAN></FONT></DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><FONT class="Apple-style-span" face="Arial" size="2"><SPAN class="Apple-style-span" style="font-size: 10px;">• Using the </SPAN></FONT><FONT class="Apple-style-span" face="Arial" size="2"><SPAN class="Apple-style-span" style="font-size: 10px;"><B>eval </B></SPAN></FONT><FONT class="Apple-style-span" face="Arial" size="2"><SPAN class="Apple-style-span" style="font-size: 10px;">property other than via a direct call.</SPAN></FONT></DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><FONT class="Apple-style-span" face="Arial" size="2"><SPAN class="Apple-style-span" style="font-size: 10px;">• Errors in regular expression literals.</SPAN></FONT></DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><FONT class="Apple-style-span" face="Arial" size="2"><SPAN class="Apple-style-span" style="font-size: 10px;">• Attempts to call PutValue on a value that is not a reference (for example, executing the assignment statement 3=4).</SPAN></FONT></DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><FONT class="Apple-style-span" face="Arial" size="2"><SPAN class="Apple-style-span" style="font-size: 10px;">An implementation shall not report other kinds of runtime errors early even if the compiler can prove that a construct cannot execute without error under any circumstances. An implementation may issue an early warning in such a case, but it should not report the error until the relevant construct is actually executed.</SPAN></FONT></DIV><DIV><BR><BLOCKQUOTE type="cite"><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">In IE ++a++ etc are reported as runtime errors.</DIV></BLOCKQUOTE><DIV><BR class="khtml-block-placeholder"></DIV>It's allowed to, per the above chapter and verse.</DIV><DIV><BR><BLOCKQUOTE type="cite"><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">Seamonkey<BR></DIV></BLOCKQUOTE><DIV><BR class="khtml-block-placeholder"></DIV>(SpiderMonkey)</DIV><DIV><BR><BLOCKQUOTE type="cite"><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "> code goes directly to MemberExpression after matching ++/--,</DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">is this the intention? If so, why not in spec?</DIV></BLOCKQUOTE><DIV><BR class="khtml-block-placeholder"></DIV>The spec intentionally under-specifies to allow for different implementation strategies.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>IMHO, the ES1-3 specs do this too much, and we are trying to improve the situation for ES4. Note however that C, Scheme, and lots of other languages under-specify even more aggressively. JS is different, because interoperation across browsers and other "JS engines" is more the rule than for other languages, which may cluster in source form in silos where only one compiler is used. For fun, read through Dawson Engler's <A href="http://www.stanford.edu/~engler/spin05-coverity.pdf">http://www.stanford.edu/~engler/spin05-coverity.pdf</A> some time.</DIV><DIV><BR><BLOCKQUOTE type="cite"></BLOCKQUOTE></DIV>/be<BR></BODY></HTML>