ECMAScript Harmony

Maciej Stachowiak mjs at
Sun Aug 17 03:33:29 PDT 2008

On Aug 16, 2008, at 10:19 PM, Yuh-Ruey Chen wrote:

> It seems like slashdot has a story on this, and as usual, it's
> completely misleading and sensationalist, and anti-MS (without
> mentioning any other ES4 dissenters) to boot:

It's hard to control stories like this, except by repeating what we  
think is the most sensible point of view, i.e. that peace and unity in  
the world of ECMAScript is within sight and is most definitely a good  

  - Maciej

> sigh...
> Brendan Eich wrote:
>> It's no secret that the JavaScript standards body, Ecma's Technical
>> Committee 39, has been split for over a year, with some members
>> favoring ES4, a major fourth edition to ECMA-262, and others
>> advocating ES3.1 based on the existing ECMA-262 Edition 3 (ES3)
>> specification. Now, I'm happy to report, the split is over.
>> The Ecma TC39 meeting in Oslo at the end of July was very productive,
>> and if we keep working together, it will be seen as seminal when we
>> look back in a couple of years. Before this meeting, I worked with
>> John Neumann, TC39 chair, and ES3.1 and ES4 principals, especially
>> Lars Hansen (Adobe), Mark Miller (Google), and Allen Wirfs-Brock
>> (Microsoft), to unify the committee around shared values and a common
>> roadmap. This message is my attempt to announce the main result of
>> the meeting, which I've labeled "Harmony".
>> Executive Summary
>> The committee has resolved in favor of these tasks and conclusions:
>> 1. Focus work on ES3.1 with full collaboration of all parties, and
>> target two interoperable implementations by early next year.
>> 2. Collaborate on the next step beyond ES3.1, which will include
>> syntactic extensions but which will be more modest than ES4 in both
>> semantic and syntactic innovation.
>> 3. Some ES4 proposals have been deemed unsound for the Web, and are
>> off the table for good: packages, namespaces and early binding. This
>> conclusion is key to Harmony.
>> 4. Other goals and ideas from ES4 are being rephrased to keep
>> consensus in the committee; these include a notion of classes based
>> on existing ES3 concepts combined with proposed ES3.1 extensions.
>> Detailed Statement
>> A split committee is good for no one and nothing, least of all any
>> language specs that might come out of it. Harmony was my proposal
>> based on this premise, but it also required (at least on the part of
>> key ES4 folks) intentionally dropping namespaces.
>> This is good news for everyone, both those who favor smaller changes
>> to the language and those who advocate ongoing evolution that
>> requires new syntax if not new semantics. It does mean that some of
>> the ideas going back to the first ES4 proposals in 1999, implemented
>> variously in JScript.NET and ActionScript, won't make it into any ES
>> standard. But the benefit is collaboration on unified successor
>> specifications to follow ES3, starting with ES3.1 and continuing
>> after it with larger changes and improved specification techniques.
>> One of the use-cases for namespaces in ES4 was early binding (use
>> namespace intrinsic), both for performance and for programmer
>> comprehension -- no chance of runtime name binding disagreeing with
>> any earlier binding. But early binding in any dynamic code loading
>> scenario like the web requires a prioritization or reservation
>> mechanism to avoid early versus late binding conflicts.
>> Plus, as some JS implementors have noted with concern, multiple open
>> namespaces impose runtime cost unless an implementation works
>> significantly harder.
>> For these reasons, namespaces and early binding (like packages before
>> them, this past April) must go. This is final, they are not even a
>> future possibility. To achieve harmony, we have to focus not only on
>> nearer term improvements -- on "what's in" or what could be in --  we
>> must also strive to agree on what's out.
>> Once namespaces and early binding are out, classes can desugar to
>> lambda-coding + Object.freeze and friends from ES3.1. There's no need
>> for new runtime semantics to model what we talked about in Oslo as a
>> harmonized class proposal (I will publish wiki pages shortly to show
>> what was discussed).
>> We talked about desugaring classes in some detail in Oslo. During
>> these exchanges, we discussed several separable issues, including
>> classes, inheritance, like patterns, and type annotations. I'll avoid
>> writing more here, except to note that there were clear axes of
>> disagreement and agreement, grounds for hope that the committee could
>> reach consensus on some of these ideas, and general preference for
>> starting with the simplest proposals and keeping consensus as we go.
>> We may add runtime helpers if lambda-coding is too obscure for the
>> main audience of the spec, namely implementors who aim to achieve
>> interoperation, but who may not be lambda-coding gurus. But we will
>> try to avoid extending the runtime semantic model of the 3.1 spec, as
>> a discipline to guard against complexity.
>> One possible semantic addition to fill a notorious gap in the
>> language, which I sketched with able help from Mark Miller: a way to
>> generate new Name objects that do not equate as property identifiers
>> to any string. I also showed some sugar, but that is secondary at
>> this point. Many were in favor of this new Name object idea.
>> There remain challenges, in particular getting off of the untestable
>> and increasingly unwieldy ES1-3.x spec formalism. I heard some
>> generally agree, and no one demur, about the ES4 approach of using an
>> SML + self-hosted built-ins reference implementation (RI).
>> We are going to look into stripping the RI of namespaces and early
>> binding (which it uses to ensure normative self-hosted behavior, not
>> susceptible to "user code" modifying the meaning of built-ins),
>> simplifying it to implement ES3.1plus or minus (self-hosted built-ins
>> may require a bit more magic). More on that effort soon.
>> ES3.1 standardizes getters and setters that were first implemented at
>> Mozilla and copied by Apple and Opera. More such de-facto
>> standardization is on the table for a successor edition in the
>> harmonized committee.
>> I heard good agreement on low-hanging "de-facto standard" fruit,
>> particularly let as the new var, to match block-scoped const as still
>> proposed (IIRC) in 3.1. Also some favorable comments about simple
>> desugarings such as expression closures and destructuring assignment,
>> and other changes in JS1.7 and 1.8 that do not require new runtime
>> semantic models.
>> Obviously, these require new syntax, which is appropriate for a major
>> post-3.1 "ES-harmony" edition. Syntax is user interface, there's no
>> reason to avoid improving it. What's more, the intersection semantics
>> of extended ES3 implementations conflict and choke off backward-
>> compatible *semantics* for syntax that may even parse in all top four
>> browsers (e.g., functions in blocks).
>> Both the appropriateness of new syntax, and the need to make
>> incompatible (with ES3 extensions) semantic changes, motivate opt-in
>> versioning of harmonized successor edition. I believe that past
>> concerns about opt-in versioning requiring server file suffix to MIME
>> type mapping maintenance were assuaged (browsers in practice, and
>> HTML5 + RFC 4329, do not consider server-sent Content-Type -- the web
>> page author can write version parameters directly in script tag type
>> attributes).
>> Some expressed interest in an in-language pragma to select version;
>> this would require immediate version change during parsing. It's a
>> topic for future discussions.
>> The main point, as important as cutting namespaces in my view, is
>> that the committee has a vision for extending the language
>> syntactically, not trying to fit new semantics entirely within some
>> combination of existing "three of four top browsers" syntax and
>> standard library extensions.
>> As Waldemar Horwat (Google) said on the final day, the meeting was
>> seminal, and one of the most productive in a long while. Much work
>> remains on 3.1 and Harmony, but we are now on a good footing to make
>> progress as a single committee.
>> /be
>> _______________________________________________
>> Es3.x-discuss mailing list
>> Es3.x-discuss at
> _______________________________________________
> Es-discuss mailing list
> Es-discuss at

More information about the Es-discuss mailing list