<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">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.<div><br></div><div>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".</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>/be</div><div><br><div><div>On Jan 9, 2012, at 12:09 PM, Allen Wirfs-Brock wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Jan 8, 2012, at 9:26 PM, Brendan Eich wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div>On Jan 8, 2012, at 4:53 PM, Mark S. Miller wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">On Sun, Jan 8, 2012 at 10:32 AM, Brendan Eich <span dir="ltr"><<a href="mailto:brendan@mozilla.com">brendan@mozilla.com</a>></span> wrote:<div>[...]</div><div><br></div><div>All cool with the above. Thanks.</div><div>
<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div>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.</div>
</div></blockquote><div><br></div><div>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?</div></div></div></blockquote><div><br></div>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!</div><div><br></div><div>HTH,</div><div><br></div><div>/be</div><div><br></div></div></blockquote><div><br></div><div>I've been thinking about this, but I'm not yet certain about a preferred approach.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>Allen</div><div><br></div><div><br></div><div><br></div></div></div></blockquote></div><br></div></body></html>