FTR (a broken record, sorry), I think we will do a big disservice to interoperation in practice (as enjoyed by future web devs) if we essentially fork the spec and mutate one copy (even excluding Clause 15) to be ES6.
I'm still pretty sure implementations will not fork their non-library codebases. Mozilla's won't. So that means the spec will be the only unconsolidated "implementation". Yes, new features (especially around parameters) may combine with old (arguments). Let's do the case analysis and see how bad this must be. I think it's strictly less bad on balance, weighing the cost to implementors, than forking. Forking the spec also raises the risk of more incompatible changes than those (few, almost none) that we intended. I'd rather bail on completion reform back to ES5 strict runtime semantics if that is what it takes to keep a consolidated/minimized spec. /be On Jan 9, 2012, at 12:09 PM, Allen Wirfs-Brock wrote: > > 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
