Implementor Question
On Oct 29, 2007, at 10:56 AM, Yehuda Katz wrote:
Is there any reason browser vendors couldn't continue to ship the
old ES3 interpreter, and make it available for <script type="text/ javascript"> and make ES4 available for <script type="application/ javascript"> or <script type="application/es4">.
Browsers not bundled with operating systems, therefore downloaded
voluntarily by users, cannot afford two engines. Even more to the
point: browsers targeting phones and other small devices cannot
afford two engines. And there is no need for two engines, since ES4
is a superset of ES3.
The overview discusses this a bit; so do my posts at the LtU thread.
See in particular:
lambda-the-ultimate.org/node/2504#comment-37607
Note the cyclic leak problem, a subset of the distributed GC problem.
That way, ES4 would not be capable of breaking anything, because
the same old ES3 interpreter would be running old code.
ES4 as implemented won't break any ES3 code, if we do our jobs -- and
we are, in full view of everyone here (see bugs.ecmascript.org).
The nice thing about the assertion that ES4 will break the web is
that it is falsifiable within the next year. But it's also nonsense
based on recent history, and on first principles.
The general "break the web" argument against JS evolution is old as
the hills. We've been evolving the language in Mozilla for years,
feeding results into Editions 2-4, while also engineering more IE
compatibility in order to help Firefox gain market share. Obviously
something is working.
The "break the web" sky did not fall, and it won't fall on account of
ES4. The best thing Microsoft could hope for would be other browsers
committing suicide by breaking the web. We at Mozilla are anything
but suicidal.
But again, two engines don't cut it, for footprint and memory
reasons. And two engines are intentionally unnecessary by the design
of ES4.
Brendan Eich wrote:
But again, two engines don't cut it, for footprint and memory
reasons. And two engines are intentionally unnecessary by the design
of ES4.
(Catching up on this thread...)
An additional technical aspect of the language, for newcomers who may not have noticed it:
It is also quite intentionally unnecessary in the ES4 design to use anything like an AOT-compiler, static typechecker, or fancy early-binding toolchain. It's designed to correctly work with last-minute checking in a lazy, lightweight, dynamic implementation. This was a strong technical requirement made by several committee members during 2006 (Opera and Microsoft in particular, iirc), and the committee has respected and pursued this goal.
Nearly a dozen alternative semantics were proposed and hashed out by our visiting experts in type theory, in order to overcome member dissatisfaction with adopting disjoint AS3-like "tilde and bang" modes with (from what I understand) somewhat differing semantics.
But again, two engines don't cut it, for footprint and memory reasons. And two engines are intentionally unnecessary by the design of ES4.
Not to mention the pains of making the two engines interoperable. In Flash, the new VM is not compatible with the old, and you have to go to extreme lengths to communicate between the two. Using one VM in Flash is much harder problem because the compiler is separate, AS2 was not completely compliant, and the files are already compiled into incompatible formats when they are loaded. Flash developers are dealing with that when it crops up, but the wider web can't be expected to do that, and it doesn't make sense to push that burden onto browser manufacturers either.
Peter
Is there any reason browser vendors couldn't continue to ship the old ES3 interpreter, and make it available for <script type="text/javascript"> and
make ES4 available for <script type="application/javascript"> or <script
type="application/es4">.
That way, ES4 would not be capable of breaking anything, because the same old ES3 interpreter would be running old code. That said, people could use the back-compatibility feature of ES4 to incrementally update their code by switching the MIME-type.
I think this one minor implementation detail could remove the "this new language will break your code" argument for once and for all. And it would ALREADY be the case with ScreamingMonkey. All it would require would be that FF4 (or whichever version ships with ES4) continues to support the old interpreter.
Is this sane?