<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div>On Oct 13, 2010, at 4:31 PM, Mark S. Miller wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div>Recently, I met with the Google V8 team for two full days. One message that came through loud and clear, that I said I would relay to the list, is "please, no more modes."</div></blockquote><div><br></div>If this is an attempt to avoid &lt;script type="harmony"&gt; (harmony a placeholder for something more RFC4329-conformant), it's not going to work.</div><div><br></div><div>I dislike modes. Who doesn't? But this sounds like the "Versioning is an anti-pattern" shibboleth I've heard recently re: WebSockets. It does not reflect reality. At the limit, it's dishonest.&nbsp;The Web has grown with incompatible changes (e..g. ES1-5, CSS table layout, XHR), some of which were forced without a version change other than the usual user-agent revisions -- which forced content authors to do user-agent sniffing.</div><div><br></div><div>We need to face the music and do the right thing here: Harmony has new syntax, not simply new keywords. This means incompatible Harmony content must not be sent to downrev user agents. This, plus RFC4329, lead us to conclude that we should use a new &lt;script type="..."&gt; version parameter, if not a whole new type attribute value.</div><div><br></div><div><br><blockquote type="cite"><div>Since we almost never get to retire anything that old code depends on, addition of modes (like "use strict") adds to implementation complexity. They understand why we needed to introduce the "use strict" mode switch specifically. But as we go forward, they'd really like to see ES-Harmony avoid further mode switches. If we keep ES-Harmony practically[1] upwards compatible from ES5/strict, then on a browser supporting ES-Harmony, "use strict" can be the way to opt in to harmony as well.</div></blockquote><div><br></div>This can't work if new syntax not specified by ES5 follows the "use strict".</div><div><br></div><div><br><blockquote type="cite">
<div>This has several implications.</div><div><br></div><div>* New harmony keywords should already be reserved in ES5/strict. Or at least be so rare in actual code that their introduction does not create a practical conflict. (This restriction need not apply to contextually reserved words, provided that the context is one which would otherwise cause a syntax error.) AFAICT, all the already-accepted harmony proposals (&lt;<a href="http://wiki.ecmascript.org/doku.php?id=harmony:proposals">http://wiki.ecmascript.org/doku.php?id=harmony:proposals</a>&gt;) obey this restriction.</div></blockquote><div><br></div>We don't know what Harmony is. Unless you have a time machine <i>and</i> there's only one universe, we can't future-proof yet.</div><div><br></div><div>Worse, new keywords are <i>not</i>&nbsp;so rare that they do not create practical conflicts. We at Mozilla did the leg work here. We took the effort to implement let and yield (let is in flux now in TC39, for the better but still the "better var", and anyway, this was 2006 when ES4 was going) in Firefox 2 / JS1.7. We found real sites using let and yield as unqualified names (parameter names, IIRC). Contextual keyword reservation did not help.</div><div><br></div><div><br><blockquote type="cite">
<div>* Likewise, new properties or global variables should be unlikely to conflict with those in existing code, though with feature testing this is a softer constraint. After all, ES5 (barely) survived the introduction of the new "JSON" global and (more easily) survived the introduction of the new reflective APIs. Accepted harmony proposals would add globals "Proxy" and "WeakMap" and the methods "Object.getPropertyDescriptor" and "Object.getPropertyNames". My guess is that all these are adequately non-conflicting.</div></blockquote><div><br></div>Proxy is shipping in Firefox 4 betas. No problems reported.</div><div><br></div><div>Simple modules will help here, but we need to finish the spec and prototype and user-test. We can't future-proof yet.</div><div><br></div><div><br><blockquote type="cite">
<div>* ES5/strict implementations as deployed in non-beta releases should obey &lt;<a href="http://wiki.ecmascript.org/doku.php?id=conventions:recommendations_for_implementors">http://wiki.ecmascript.org/doku.php?id=conventions:recommendations_for_implementors</a>&gt;. If they don't, then either a separate opt-in will be necessary or we will have to retreat from some of the accepted harmony proposals. For example, if browsers deploy a harmony-incompatible semantics for "let", "const", and nested named functions, and if ES5/strict code comes to depend on those non-standard extensions, then without an additional opt-in it becomes impossible to deploy harmony without breaking that code.</div></blockquote><div><br></div>The conventions aren't enough. See above.</div><div><br></div><div>The point about let, const, and function in block is good but I'll take it up in a separate message.</div><div><br></div><div><br><blockquote type="cite">
<div>Going through the active strawmen, most are not particularly problematic on these grounds. Although &lt;<a href="http://wiki.ecmascript.org/doku.php?id=strawman:obj_initialiser_constructors">http://wiki.ecmascript.org/doku.php?id=strawman:obj_initialiser_constructors</a>&gt; is presented as if using a "constructor" keyword, if it goes forward I think we all expect it would actually use "class" instead.</div></blockquote><div><br></div>I don't see how reserving class (as everyone already is) helps. The new code will look like this:</div><div><br></div><div>&lt;script&gt;</div><div>&nbsp;&nbsp; &nbsp;"use strict";</div><div>&nbsp;&nbsp; &nbsp;class SuperDuper {...}</div><div>&lt;/script&gt;</div><div><br></div><div>An ES5-or-below browser will read this and choke. What good does shipping this without a new &lt;script type=...&gt; type attribute value do?</div><div><br></div><div><br><blockquote type="cite"><div> However, the module proposal currently uses "module" as a keyword, which is not reserved and is probably in active use. Could we use (the already reserved) "package" instead?</div></blockquote><div><br></div>There's no need for this. We should stick to module, since it can occur only in limited contexts (at the start of SourceElements).</div><div><br></div><div>But the whole premise that we can (a) guess the future; (b) avoid conflicts even as we add new syntax; is false.</div><div><br></div><div><br><blockquote type="cite"><div>[1] Making an ES5/strict error condition be a non-error in harmony is not formally upwards compatible, since old code could depend on that error.&nbsp;In the Caja design documents, we'd say that ES5/strict is a "fail stop subset" of ES-Harmony. Looked at from the other direction, such fail-stop supersetting is often&nbsp;practically&nbsp;upwards compatible, to be examined on a case by case basis, especially when the error in question is a syntax error.&nbsp;</div>
<meta charset="utf-8"></blockquote></div><br><div>A syntax error is not enough. It will not be detectable by old browsers so that they can fall back on ES3- or ES5-level content. It will cause a wasted script load, which blocks rendering in many browsers (especially old ones). It will present error reports on consoles, confusing users and wasting more cycles.</div><div><br></div><div>I don't think the "no more modes" plea is a coherent request or requirement. Can someone restate it in a credible, future-proof way?</div><div><br></div><div>Hixie and Maciej tried a few years ago, in effect (from memory, which may be wrong) trying to allow arbitrary syntax of the form</div><div><br></div><div>&nbsp;&nbsp;keyword ( expr ) { statements }</div><div><br></div><div>so that ES5 would have standardized syntax error recovery when keyword was unrecognized, and then future editions could add new keywords and content authors could at least hope that such statement constructs could be skipped by ES5-level downrev browsers.</div><div><br></div><div>This attempt foundered on ASI and regexp syntax. Waldemar remembers the details.</div><div><br></div><div>But anyway, this idea did not help let syntax, or yield as an operator (yield as a function is not problematic, but it stinks like eval). This simply was not future proof.</div><div><br></div><div>Worse, it provide no fallback mechanism for old browsers to select pre-Harmony content. A &lt;script type="harmony"&gt; tag doesn't either, by itself. Wherefore the __MAX_ECMASCRIPT_VERSION__ idea from</div><div><br></div><div><a href="http://wiki.ecmascript.org/doku.php?id=proposals:versioning">http://wiki.ecmascript.org/doku.php?id=proposals:versioning</a></div><div><br></div><div>mentioned in the current strawman:</div><div><br></div><div><a href="http://wiki.ecmascript.org/doku.php?id=strawman:versioning">http://wiki.ecmascript.org/doku.php?id=strawman:versioning</a></div><div><br></div><div>This is the place to focus effort.</div><div><br></div><div>/be</div></body></html>