Hi Andy, > As you probably know, the ECMA TC39 committee is slowly approaching > consensus on a new revision of the ECMAScript language. The interim > results of this process have gone under various names: Harmony, ES.next, > and ES6. They are the same thing. This mail is intended to open the > discussion on what to do now regarding ES6 in JSC.
Let's stick with using the name ES6. Per Brendan's comments I guess ES.next is probably more correct right now, but the meaning of ES.next is presumably liable to change once ES6 is released! > ES6 does not yet define how extended mode is entered, however. Some ES6 > functionality is incompatible both with classic mode and with strict > mode, so it has to be an opt-in thing, perhaps via <script > type="application/ecmascript;version=6">. > > However, there is a subset of ES6 that is compatible with strict-mode. > I am interested in implementing parts of this set. Specifically, I am > interested in implementing block-scoped `let' and `const'. > > I think it would be fine to enable the compatible subset of ES6 within > all strict-mode code. It would not be incompatible with existing code > on the web. V8 seems likely to go in this direction as well, and > SpiderMonkey already has done so. Effectively, strict mode could become > "compatible extended mode", globally. As it stands, ES6 introduces a mix of new features (new syntax, which would have been syntax errors in ES5), and changes to the semantics of existing ES5 syntax (typeof null, resolving to global object). So far as the new features are concerned, I don't think we want to make them opt-in and artificially tie them to ES5 strict mode – these features have nothing to do with ES5 strict. If we do want these features to require an explicit opt-in, then they should be restricted to ES6 (extended mode). However I think it is probably unnecessary and undesirable to restrict them at all – instead we should just make them available to all scripts. In practice I don't think there will be any syntax extensions that would be backwards compatible from ES6 to ES5-strict, but not compatible with ES5. We have an existing extension to provide limited support for 'const' in classic mode for web compatibility reasons, but provided that it does not break the web to do so it would be better to replace this with ES6 compatible const semantics, rather than unnecessarily maintaining two separate and incompatible behaviours. Technically 'let' is not a reserved word outside of strict mode in ES5 which could be an issue, but I think even this can probably be support well in classic mode by handling it as a contextual keyword (compatible modulo a minor auto semicolon insertion quirk, I think). Similar for 'yield', and this is likely to be even less of an issue given the restricted context in which it can be used. So far as changes to the semantics of existing syntax are concerned, it is certainly possible that we will need to add support for the script tag to specifying a language version (likely passed into JSC as a property of the SourceCode object). In addition we may want to consider whether it makes sense to imply extended mode within ES6 language features – e.g. if we permit module syntax as an extension in ES5, we may want to enable full ES6 semantics for all code within the body of a module. If we do, this may mean propagating state that enables extended mode when parsing, and tracking this for functions (much as we do already for strict). > "Compatible extended mode" is not a point we need to decide now, > however. Implementation work towards agreed-upon parts of ES6 is useful > in any eventuality. > > Now, it is fine enough to have an implementation of parts of ES6 behind > an #ifdef. I think though that we should get to the point that the > #ifdef is on by default, then removed entirely. We still need a bit to > indicate at parse-time whether a piece of code is extended-mode or > strict-mode. It does not seem that we need a runtime extended-mode bit, > though, as we do with strict-mode vs classic-mode. > > My current approach to this, given that the ES6 draft doesn't specify > how to enter extended mode, is to provide a global flag that turns > strict mode into compatible extended mode. We may not want to enable ES6 support by default until the spec is stable and we have a relatively complete implementation, but this shouldn't block development or prevent features from being compiled in at an earlier stage. In fact, we really need to build in all features from the point they are added, so that regression tests can be committed along with the implementation. As such enabling ES6 support should be a runtime setting rather than at compile time one. This should be done via a page setting (WebCore/pages/Settings.h), since this will make it easy for us to enable ES6 support via the WebKit interface, from DRT or a browser (JSC should be able to query this setting via JSGlobalObject). Hope this sounds sensible, G. _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
