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.
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
> (<http://wiki.ecmascript.org/doku.php?id=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
> <http://wiki.ecmascript.org/doku.php?id=conventions:recommendations_for_implementors>.
> 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
> <http://wiki.ecmascript.org/doku.php?id=strawman:obj_initialiser_constructors>
> 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
http://wiki.ecmascript.org/doku.php?id=proposals:versioning
mentioned in the current strawman:
http://wiki.ecmascript.org/doku.php?id=strawman:versioning
This is the place to focus effort.
/be_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
