[webkit-dev] JavaScriptCore and ES6

[Adam Barth]

The versioning issues in ECMAScript are tough.  We ran into these same
problems when we were working with TC39 to formulate a versioning plan
for what became ES5.  None of the alternatives are really that great,
but you likely need to pick one to make progress.

I would caution you about adding more modes to ECMAScript.  That trick
works once or twice, but if you keep adding modes over the years, you
eventually end up with something extremely complicated.  IE is
starting to suffer from this pain as their number of rendering modes
compounds with each release.

Adam


On Thu, Dec 15, 2011 at 3:38 AM, Andy Wingo <wingo at igalia.com> wrote:
> 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-discuss at 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 at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev