No more modes?

Brendan Eich brendan at mozilla.com
Fri Oct 15 10:30:02 PDT 2010


On Oct 14, 2010, at 3:47 PM, Brendan Eich wrote:

> Seriously, we don't want a version lattice with bad combinatorics. We've been over this in TC39 meetings and there are records on the wiki. The prominent memento is 3(I) at:
> 
> http://wiki.ecmascript.org/doku.php?id=harmony:harmony#means

Prior to Means 3(I), there is Goal 4 (http://wiki.ecmascript.org/doku.php?id=harmony:harmony#goals):

 Keep versioning as simple and linear as possible.

We don't have concrete plans for a "use strict" in Harmony to opt into a "stricter than ES5 strict" mode. The "no more modes" plea is good as far as it goes (just not absolute), so I hope we do not add any such Harmony-strict-mode. We're really trying not to make an N-dimensional version/mode/pragma lattice.

But, again, ES5 makes incompatible (slight) changes to the de-facto standard JS ("ES3R") language, and ES5 strict is indeed a mode. New syntax is coming, but we will build it on ES5 strict under some kind of opt-in.

The minimum opt-in mechanism, we think, is specified by RFC4329: <script type="application/ecmascript;version=6">. This works in IE9, in the sense that the script tag content is not processed (thanks to Jeff Walden for testing). Testing in older and other browsers welcome,with and without the ;version= parameter.

Markup-based version selection, to allow inline, out of line (src=) with prefetching, and downrev-browser fallback without "autoconf-style" generation of script elements, seems worth considering.


>> - Will we have to add yet another mode each time we add syntax? After enough iterations this becomes unsustainable.
> 
> Languages don't grow indefinitely but JS syntax (and semantics) are gappy enough there could be another edition that comes after the first Harmony edition. 

That was a bit too neutral-sounding.

I want to add that my strong desire is to avoid adding syntax after the "Harmony edition" (let's hope it is ES6, but we have been burned picking numbers prematurely in the past, and there's no need yet to pick a number). I'm simply skeptical about our ability to predict the future or enforce a bad prediction.

Modules should give everyone writing libraries (least of all TC39) name-conflict-free upgrade paths, along with lexical scope all the way up (no global object). If we ever get to the promised land of macros, we'll need modules (and a lot else; macros are very much a dark horse, or just a gleam in my eye).

So modules are important. Proxies too. So are let/const/function-in-block. Some less critical but worthwhile conveniences matter too, enough that they're in the harmony section of the wiki.

If you ask me, the list outlined in the last paragraph is enough for "Harmony". I'm not sure we need classes or traits in the language; more work (under way) is needed to find out.

My two cents, and as usual I reserve the right to change my mind, or coins.

/be


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20101015/36af1211/attachment.html>


More information about the es-discuss mailing list