Hello all, 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.
Here is the latest draft ES6 spec, from 7 November: http://wiki.ecmascript.org/lib/exe/fetch.php?id=harmony%3Aspecification_drafts&cache=cache&media=harmony:working_draft_ecma-262_edition_6_11-7-11.pdf Discussion takes place among committee members. Some discussion also takes place in public, on es-disc...@mozilla.org. We cannot consider implementing ES6 now, as the final document is not out, and some things are likely to change. It only makes sense to look at the features for which broad consensus exists. So, what is agreed upon in the ES6 spec? I would answer this by mentioning the parts of ES6 that folks are working on both for SpiderMonkey and for V8. These are: 1. Block-scoped `let' and `const' (https://bugs.webkit.org/show_bug.cgi?id=31813) 2. typeof 'null' -> 'null', not 'object' 3. Proxies 4. Collections (maps, sets, weak maps) Things that are not implemented by multiple JS engines, but otherwise are close to agreement: 5. Modules 6. Destructuring binding 7. Parameter default values, rest parameters 8. Quasi-literals 9. Generators, iterators, comprehensions 10. Binary data Things that will probably change: 11. Classes, <|, .{ See http://wiki.ecmascript.org/doku.php?id=harmony:proposals for more information. V8 currently compiles in support for 1-4, but disabled behind a runtime flag. I think that with the nightly Chromium builds you can run it with --harmony to enable these features. Modules are being worked on for V8, but not finished AFAIK. * * * One big problem for ES6 is "how to get there from here": how to enable the new language features without breaking the web. The current answer is to define a new mode, and allow code to opt-in to that mode. Recall that ES5 defines "strict mode", a new mode of execution for JS. Let's call the other mode "classic mode". ES6 defines a third "extended mode", which builds on strict mode, and enables the new features. 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. "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. So, those are my thoughts on this. Your feedback is welcome. I hope to have a block scope implementation finished by mid-january or so; follow https://bugs.webkit.org/show_bug.cgi?id=31813, for more information. Regards, Andy _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
