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
_______________________________________________
Es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
