No more modes?

Mark S. Miller erights at
Thu Oct 14 08:12:02 PDT 2010

On Wed, Oct 13, 2010 at 5:35 PM, Brendan Eich <brendan at> wrote:

> On Oct 13, 2010, at 4:31 PM, Mark S. Miller wrote:
> 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."
> If this is an attempt to avoid <script type="harmony"> (harmony a
> placeholder for something more RFC4329-conformant), it's not going to work.

Declaring what the conclusions of discussions must be is not helpful. I am
raising an issue. Let's discuss it.

Given <script type="harmony"> as an opt-in, I'm puzzled about how it would
work anyway. Since it is per script, not per frame, presumably

<script type="harmony">"use strict"; var e1 = eval;</script>
<script>"use strict"; var e2 = eval;</script>
<script ...>"use strict"; e1 === e2 /*results in true*/ </script>

In other words, that both harmony and non harmony code on the same page have
the same binding for the global "eval" function. In that case, what does the
following code do:

    e2(' "use strict"; var module = 8;');

This is currently legal es5/strict code. As suggested by the modules
strawman, it is not legal harmony code. es5/strict and harmony share a heap.
I do not see a good answer.

> 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. 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.
> 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 <script type="..."> version parameter, if
> not a whole new type attribute value.
> 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.
> This can't work if new syntax not specified by ES5 follows the "use
> strict".
> This has several implications.
> * 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 (<
>>) obey this
> restriction.
> We don't know what Harmony is. Unless you have a time machine *and*there's only one universe, we can't future-proof yet.
> Worse, new keywords are *not* 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.
> * 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.
> Proxy is shipping in Firefox 4 betas. No problems reported.
> Simple modules will help here, but we need to finish the spec and prototype
> and user-test. We can't future-proof yet.
> * ES5/strict implementations as deployed in non-beta releases should obey <
> 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.
> The conventions aren't enough. See above.
> The point about let, const, and function in block is good but I'll take it
> up in a separate message.
> Going through the active strawmen, most are not particularly problematic on
> these grounds. Although <
> is presented as if using a "constructor" keyword, if it goes forward I think
> we all expect it would actually use "class" instead.
> I don't see how reserving class (as everyone already is) helps. The new
> code will look like this:
> <script>
>     "use strict";
>     class SuperDuper {...}
> </script>
> An ES5-or-below browser will read this and choke. What good does shipping
> this without a new <script type=...> type attribute value do?
> 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?
> There's no need for this. We should stick to module, since it can occur
> only in limited contexts (at the start of SourceElements).
> But the whole premise that we can (a) guess the future; (b) avoid conflicts
> even as we add new syntax; is false.
> [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. 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 practically upwards compatible, to be examined on a
> case by case basis, especially when the error in question is a syntax
> error.
> 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.
> 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?
> Hixie and Maciej tried a few years ago, in effect (from memory, which may
> be wrong) trying to allow arbitrary syntax of the form
>   keyword ( expr ) { statements }
> 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.
> This attempt foundered on ASI and regexp syntax. Waldemar remembers the
> details.
> 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.
> Worse, it provide no fallback mechanism for old browsers to select
> pre-Harmony content. A <script type="harmony"> tag doesn't either, by
> itself. Wherefore the __MAX_ECMASCRIPT_VERSION__ idea from
> mentioned in the current strawman:
> This is the place to focus effort.
> /be

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list