Improving ECMAScript as a compilation target

Brendan Eich brendan at
Thu Feb 12 23:42:11 PST 2009

On Feb 12, 2009, at 10:23 PM, Peter Michaux wrote:

> On Thu, Feb 12, 2009 at 10:16 PM, Brendan Eich <brendan at>  
> wrote:
>> On Feb 12, 2009, at 9:41 PM, Peter Michaux wrote:
>>> 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".
>> Standardizing a target bytecode or even AST encoding would take no  
>> less
>> time, almost certainly more.
>> We should talk about methodMissing for Harmony.
> Great but to be clear, methodMissing was just an example of a feature
> some desire. I could have used "classes", "continuations", "threads",
> etc all of which people have tried to add to ES.

Let's not go in circles or generalize until there's nothing to talk  
about. I've argued against full continuatons, also against threads  
(see my blog). Any particular responses?

Generators inspired by Python are in JS1.7 and 1.8 (generator  
expressions), and proposed for harmony. One issue already raised:  
should Harmony depart from Python and JS1.7 by requiring some new  
keyword instead of 'function', say:

generator odds() {
   for (let i = 1; ; i += 2)
     yield i;

I'm still inclined to follow Python and re-use 'function' as it reused  
'def', for reasons given in the PEPs. People do not get confused by  
the change yield in a function makes to the meaning of the function  
(that it becomes a factory for generator-iterators). At least not in  
our experience with JS1.7+, or AFAIK with Python.

Some kind of classes as sugar, probably zero inheritance, private  
variables, public methods, probably public static methods are on the  
boards for Harmony.

A methodMissing hook came up as a late request for 3.1. Allen  
responded that it didn't fit in the schedule and suggested any such  
feature should handle property accesses as well as method calls:

Igor pointed out how call and apply won't work with a __noSuchMethod__  
mechanism tied to invocation:

You were perfectly clear in lamenting the time to get things  
standardized and then implemented, and then to wait for old browsers  
to die off (I share your lament), but there's no point in complaining  
about this general problem, or laundry-listing good and bad (IMHO :-P)  
features that may or may not have been implemented or proposed, to  
justify code generators. If we're to improve the standard language for  
either hand-coders or compilers, let's get down to brass tacks.


More information about the Es-discuss mailing list