ES6 doesn't need opt-in

Allen Wirfs-Brock allen at
Mon Jan 9 12:09:00 PST 2012

On Jan 8, 2012, at 9:26 PM, Brendan Eich wrote:

> On Jan 8, 2012, at 4:53 PM, Mark S. Miller wrote:
>> On Sun, Jan 8, 2012 at 10:32 AM, Brendan Eich <brendan at> wrote:
>> [...]
>> All cool with the above. Thanks.
>> I wrote in a previous reply that we aren't preserving ES5 as a spec referenced from ES6. ES6 will be self-contained. So I still don't grok your concern here.
>> Sorry, I missed that. In that case, I still don't understand what your plan for ES6 is. Does the ES6 spec include the state machine and an updated form of the ES5-non-strict portions of the ES5 spec, as referenced by that state machine?
> I defer to Allen, but one approach is to leave ES5-nonstrict as is, and combine strict and extended modes for the "6" in 5&6 and ES56. As you proposed!
> HTH,
> /be

I've been thinking about this, but I'm not yet certain about a preferred approach.

One alternative is to keep the current ES5 specification( both non-strict and strict) as a normative part of ECMA-262 and add a new part which is the complete specification for "ES6".  Essentially Ecma-262-6 part 1 would be the same as Ecma-262-5 (plus any errata level corrections) but excluding most of clause 15 (the builty-in library) and Ecma-262-9 part 2 would be a comprehensive specification for a language that starts with implicit ES5 strict mode (modulo completion reform and any other semantic changes) add new ES6 features and excludes ES5 "non-strict" features and semantics.  Because of the shared heap, the new clause 15 would have to apply to both the part 1 and part 2 languages.  The specification would have to include something like my state machine which determines whether the part 1 or part 2 language is to be used to process a Program.

This approach has the advantage that it simplifies the specification of the new ES6 features and minimizes the risk of unintentionally changing the specification of ES-5 non-strict features that must exist somewhere in the specification. I'm finding various places where significant changes in specification technique is required to support new feature semantics and making sure that  the rewritten specification also works for legacy (non-strict ES5).   However, this approach has the disadvantage that implementors who what to share as much logic as possible between "ES5 mode" and "ES6 mode" many have to do their own analysis of the differences and commonalities.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list