Re: [webkit-dev] JavaScriptCore and ES6

2011-12-16 Thread Gavin Barraclough 
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

Re: [webkit-dev] JavaScriptCore and ES6

2011-12-16 Thread Anne van Kesteren 
In general I think versioning is a bad idea, but out-of-band is even
worse. We'd have to change Web Workers (both constructors and
importScripts() would need to take some kind version-related
information) and everyone on the platform would instead of simply
using script have to resort back to specifying the type attribute
again. We just got rid of that!
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] JavaScriptCore and ES6

2011-12-16 Thread Brendan Eich 
On Dec 16, 2011, at 1:24 AM, Anne van Kesteren wrote:

 In general I think versioning is a bad idea, but out-of-band is even
 worse.

ES.next is going to have a

use version 6;

in-band pragma.

/be
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

[webkit-dev] JavaScriptCore and ES6

2011-12-15 Thread 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_draftscache=cachemedia=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

Re: [webkit-dev] JavaScriptCore and ES6

2011-12-15 Thread 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 wi...@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_draftscache=cachemedia=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
___
webkit-dev mailing list

Re: [webkit-dev] JavaScriptCore and ES6

2011-12-15 Thread Andy Wingo 
On Thu, 2011-12-15 at 10:36 -0800, Adam Barth wrote:
 I would caution you about adding more modes to ECMAScript.

I agree.

You probably know this, but I just realized that my original mail could
have implied that I'm on TC39, which is not the case.

Just making that particular point clear. :)

Cheers,

Andy
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] JavaScriptCore and ES6

2011-12-15 Thread Brendan Eich 
 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.

Hi Andy, one nit to pick: Harmony is the full post-ES4 agenda, not just what 
fits in any one edition. So ES.next is a subset of Harmony, and we talk about 
proposals being in Harmony vs. strawman. We consider strawman proposals 
that won't make ES.next, even as we work to finalize ES.next. We may reorder 
proposals to correct mistaken priorities or stale decisions. We try to look at 
the big picture and follow the hermeneutic spiral.

Harmony is also an approach to evolving JS (a shared set of requirements, 
goals, technical values and aesthetics if you will), as well as a set of 
evolving proposals that span future editions. See 
http://wiki.ecmascript.org/doku.php?id=harmony:harmony for requirements and 
more links.

/be
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev