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 <bren...@mozilla.com> 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. Allen
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
