No more modes?

Brendan Eich brendan at
Thu Oct 14 15:47:06 PDT 2010

On Oct 14, 2010, at 3:30 PM, Maciej Stachowiak wrote:

> My priors (before studying the thread closely):
> - I don't like modes.

It will be simpler and shorten correspondence for those who *do* like modes to say so.


> - If mode switching is necessary, I prefer in-band mode identification to external.

Why is it either/or -- either in-band or not?

> - Harmony will effectively have three modes - Harmony (with all new syntax), ES5 strict + new Harmony APIs, ES5 non-strict + new Harmony APIs.

Nope. Harmony is based on ES5 strict. No 'with', no non-strict.

APIs can be object-detected, and overwritten if they have global bindings. But with simple modules this won't be an issue -- you'll declare what you need, loading from a built-in module resource identifier ("@std", "@dom", etc. -- these are straw anti-URI made-up names).

> - It seems per the current plan all three will have to be supported indefinitely. It's highly unlikely that currently deployed ES will all get replaced on anything less than geological time scalles.
> - Is the Harmony spec going to take responsibility for defining all three of those modes, or with the latter two just be implicit in the combination of the ES5 spec and parts of the Harmony spec? I would prefer if it took responsibility for fully defining all the modes, but it's not clear if this is the current plan.

We're responsible types around here, but your three needs to be lowered to two or one (with modules).

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:

> - 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. ES5, ES3, ES2.

This was far from unsustainable. The stagnation after ES3 was worse, frankly, and it did not prevail: de-facto extensions including new syntax, and the Web was better for it.

> I feel obligated to read the thread and think about it before proposing or evaluating specific solutions.



More information about the es-discuss mailing list