[webkit-dev] JavaScriptCore and ES6

[Andy Wingo]

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