Improving ECMAScript as a compilation target

Brendan Eich brendan at mozilla.com
Thu Feb 12 21:17:46 PST 2009


On Feb 12, 2009, at 8:07 PM, Peter Michaux wrote:

> About five months ago I posted here about improving ECMAScript as a
> compilation target.
>
> https://mail.mozilla.org/pipermail/es-discuss/2008-September/007652.html
>
> I was disappointed that there weren't any responses to that email.
> Folks were probably busy with other concerns. I also thought there
> might be some motivation to avoid making ECMAScript an improved
> compilation target as that may reduce the number of programmers
> working directly in ECMAScript. Perhaps that goes against the goals of
> this group.

That does not make sense. It assumes there is some control by the  
committee on the number of programmers hand-coding ECMAScript. There  
isn't. Rather, it's extremely unlikely that hand-coding JS will cease  
any time soon, no matter the increase in code generators.

Therefore the language should not have footgun/power-tools of the kind  
a compiler writer would want in a memory-safe compilation target  
language (e.g. call/cc). A while ago when this topic came up (well  
before your last post on the subject), in https://mail.mozilla.org/pipermail/es-discuss/2006-June/003482.html 
, Lars wrote:

> I don't think that being a compiler target is among the core use cases
> for ECMAScript 4.  (Nor do I think it should be.)  I also don't think
> that a pragmatic programming language like ECMAScript should follow
> Scheme, say, in providing a minimalist and powerful core on which a
> great variation of abstractions can be written by the initiated.
> Instead I think ECMAScript needs to be a rich language with features
> that are immediately useful to its core audiences, and which play well
> with each other in the sense that they have unsurprising consequences
> when composed.

If you s/ECMAScript 4/ECMAScript Harmony/ I still agree completely,  
and I expect others on the committee do too. We're still focused on  
programming in the large, higher integrity, lexical scope, and  
appropriate improvements to usability and expressiveness for a large  
number of programmers -- not optimization for automatic code generators.

As for trying to be both a desert topping and a floor wax, that trick  
never works in reality.

Certainly we can make things like ES3.1 strict mode better for certain  
code generators such as Caja and AdSafe, but by adding integrity  
property support. This helps hand coders too, we believe -- even if we  
do not expect "use strict" to predominate any more than code  
generation to take over in the near term.


> The general browser scripting world is still programming in
> ECMAScript; however, the number of projects that compile to ECMAScript
> are increasing. I expect to see this trend continue to grow.

Who knows what the balance will be, but again: hand-coding will  
predominate for the near term and it's unlikely to drop to an  
insignificant fraction of the JS on the web.

Note that more than a few code generators take a source language  
related to JS (subset, close cousin, slightly extended dialect). This  
is not a coincidence; it eases the pain of inevitable abstraction  
leaks and helps debugging. It matches impedances, reducing risk of  
semantic conflicts and performance surprises.


> I wrote the following as a blog post recently. I don't presume anyone
> here reads my blog so am submitting it here. I am interested to know
> if attitudes have changed or people are warming up to the idea of
> changing ECMAScript intentionally to make it a better compilation
> target.

If I wanted a safe intermediate form, I would look at arithmetic  
coding techniques that self-verify (so that you can't express other  
than well-formed programs), not bytecode and not JS source. It's IMHO  
very unlikely that TC39 will standardize a bytecode for JS. An AST  
encoding has better chances and better properties including self- 
verification and view-source-ry.


> The same is happening in the browser. Developers are compiling many
> languages down to ECMAScript ("they byte code of the browser"). GWT
> and Cappuccino are two well know examples. These projects are
> overruling the idea that they must write in ECMAScript to create
> browser apps. They don't have to wait for the ECMAScript committee to
> standardize methodMissing, for browsers to implement it and for old
> browsers to disappear. Ten years? No way! They have methodMissing
> now!!

SpiderMonkey has had __noSuchMethod__ for years. The "Ten years"  
complaint you make seems to be against "the ECMAScript committee", but  
the committee mothballed the old ES4/JS2 proposals in 2003. Why?  
Because of monopoly stagnation of the web by one company, not by the  
committee. By pretending the committee is to blame you let that  
company off the hook and perpetuate the problem you're decrying. That  
doesn't make sense.

But if your only solution is to use a code generator, great. Don't  
expect code generation to become a focus of the committee, however.  
It's more likely to be addressed by competition among implementations,  
as you note later:


> Is it inevitable that browser makers and/or the ECMAScript standard
> group will add features to ECMAScript specifically to make it a better
> compilation target or expose actual byte code? By making ECMAScript
> engines faster, browser makers have already started. Should the effort
> to make the browser a better compilation target be encouraged and
> expedited so the long drawn out "eventually" can come sooner?

Why do you assume something not in evidence? Who says "eventually" or  
"inevitabl[y]" there will be standard bytecode? Even if you end up  
accurately predicting some future event, doing so prematurely based on  
a hunch does not help us now in any way. Projecting enthusiastically  
about hypothetical outcomes does not accelerate the process of  
developing a suitable common language for hand-coders and code- 
generators.

The JVM bytecode is a counter-example and we are not going to  
standardize anything like it in the near term (next few years).

/be



More information about the Es-discuss mailing list