Improving ECMAScript as a compilation target
petermichaux at gmail.com
Thu Feb 12 21:41:51 PST 2009
On Thu, Feb 12, 2009 at 9:17 PM, Brendan Eich <brendan at mozilla.com> wrote:
> On Feb 12, 2009, at 8:07 PM, Peter Michaux wrote:
> SpiderMonkey has had __noSuchMethod__ for years. The "Ten years" complaint
> you make seems to be against "the ECMAScript committee",
Not at all and it is unfortunate it came across that way. It is at the
whole chain of events which is long: "for the ECMAScript committee to
standardize methodMissing, for browsers to implement it and for old
browsers to disappear".
>> 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.
I didn't make predictions. I asked questions on purpose.
If a "common language for hand-coders and code-generators" is
desirable, isn't it necessary to consider the code-generator part?
That was really the question of my whole post: should we be
considering the code-generation part perhaps more than we are.
More information about the Es-discuss