Discuss
  • New ES6 spec draft (Rev 22, Jan 20, 2014)

New ES6 spec draft (Rev 22, Jan 20, 2014)

# Allen Wirfs-Brock (12 years ago)

The draft is available at harmony:specification_drafts#january_20_2014_draft_rev_22

Big news: Promise and Module Loading/Linking. Still a few loose ends, but we're getting there.

Changes include:

  • Promises
  • Module loading/linking semantics
  • Internal Tasks
  • Realm Objects
  • Loader Objects
  • updated with binding for unscopable names as discussed at Sept 2013 meeting
  • An unscopables object is now an ordinary object whose own property keys are the unscopable names.
  • Fixed sticky mode bugs in RegExpExec
  • Provided algorithm for RegExp.prototype.replace and updated other RegExp methods
  • Fixed RegExp matcher algoritm to normalize results of Unicode mode matches back to UTF-16
  • Grammar parameter tweaks related to use of yield in generator parameters.
  • Simplified eval/arguments restrictions. They never are applied in non-strict code
  • Added tail call detection for arrow functions with expression bodies
  • clarified unicode escaping in IdentifierNames and keywords
  • The default class constructor definition is now constructor(...args) {return super (...args);) if one is not explicitly provided (adding explicit return is the change)
  • Fixed Invoke abstract operation to correctly handle invokes on primitive values. Implementations of built-ins that are * specified using Invoke should make sure they work correctly in cases where Invoke might be validly applied to a primitive
  • Function.prototype.toMethod, replaces RebindSuper abstraction operation with CloneMethod
  • Eliminated comparator optional argument to Map and Set constructor
  • Removed vague overflow/underflow requirements from Math.Hypoth
  • Creating a Proxy requires use of new.
  • No line terminator allow before the * in yield *.
  • extends clause of a class declaration is now a LeftHandSideExpression
  • Completely redo of object invariants section.
# Tom Van Cutsem (12 years ago)

I really like the way the ES6 spec is coming together. Generally the way in which abstract ops are used and internal methods are specified is much clearer and more uniform in ES6 than in ES5. Also, the table of contents is much better structured. I like your classification according to indexed collections, keyed collections, control abstraction objects, reflection, etc. These editorial issues are not always fully appreciated, but +1 to them.

# Kevin Smith (12 years ago)

Couple of nits WRT modules:

  • The instantiationRequest interface is defined as having two properties: "execute" and "deps". I believe "deps" should be spelled "dependencies" to match the naming conventions throughout the rest of the document. Besides that, there is no reason that I can see to optimize keystrokes for that property name.

  • The loader for the current realm is specified as a property of the global object named "System". This has always bothered me for two reasons:

    1. The word "system" does not describe the object. It is a loader, not a "system".

    2. The current loader is an instance of the Loader type. It is incongruent to name an instance with a capitalized identifier. I believe it would be more appropriate to provide access to the current loader via a getter on the Loader or Realm constructor. For example:

      Realm.loader
Loader.current
etc...

Thanks - it's looking great!

# Sam Tobin-Hochstadt (12 years ago)

On Tue, Jan 21, 2014 at 9:29 AM, Kevin Smith <zenparsing at gmail.com> wrote:

  1. The current loader is an instance of the Loader type. It is incongruent to name an instance with a capitalized identifier. I believe it would be more appropriate to provide access to the current loader via a getter on the Loader or Realm constructor. For example:
Realm.loader
Loader.current
etc...

First, there are plenty of standard bindings on the global object that are not constructors and yet are capitalized -- Math is a prime example here.

Second, there's no reason that access to a particular loader and access to the Realm or Loader constructors should be related.

Third, anything in the .current style is introducing inexplicable magic into the platform to have the value of the property vary depending on a property that code otherwise can't observe.

Fourth, there can be multiple loaders associated with a given Realm.

Fifth, the binding for System is not a general mechanism for accessing loaders -- it is a binding for a particular one, the one provided by the host environment. it shouldn't be confused with such a general mechanism (which, as I say above, would be a bad idea anyway).

# John Barton (12 years ago)

On Mon, Jan 20, 2014 at 7:42 PM, Allen Wirfs-Brock <allen at wirfs-brock.com>wrote:

  • Module loading/linking semantics
  • Internal Tasks
  • Realm Objects
  • Loader Objects

We have been implementing module loading based on and giving feedback to jorendorff/js-loaders. I was under the impression that the standards committee had temporarily delegated the module-loading to js-loaders. Were we wrong or can someone clarify what we should be paying attention to?

# Allen Wirfs-Brock (12 years ago)

js-loaders is both the initial spec. draft and the initial prototype of the module subsystem. What we have now is the integration of the that initial draft into the actual ES6 spec. In doing that there is some editorial renaming and refactoring intended to improve the spec. clarity and the logical layer of the entire ES6 spec. There shouldn't be any semantic differences, except where there were ambiguities or open issues and those we will be discussing.

Issues relating to the specification need to go through bugs.emcascript.org so I can track and resolve them them for the official specification. I just added a "modules" component to the "Draft for 6th Edition" product. I suggest you run all feature/specification related issues through there. Dave, Sam, and Jason will all be CC'd on those.

Issues relating specifically to Jason's prototype can probably continue to be handled on github.

# Kevin Smith (12 years ago)

First, there are plenty of standard bindings on the global object that are not constructors and yet are capitalized -- Math is a prime example here.

Math (and Reflect, JSON, etc) are functioning not as objects with per-instance state, but as namespaces. Infinity is a value object, but doesn't carry per-instance state like a loader does.

Fifth, the binding for System is not a general mechanism for accessing loaders -- it is a binding for a particular one, the one provided by the host environment. it shouldn't be confused with such a general mechanism (which, as I say above, would be a bad idea anyway).

Granted. My point was just that it's awkward to have an object which is an instance of a provided type, carrying per-instance state, denoted by a capitalized global property name. And that "System" as a name (by itself) doesn't describe the concept.

Just my opinion - no big deal. The module design is very lovely. : )

# Jason Orendorff (12 years ago)

On Mon, Jan 20, 2014 at 9:42 PM, Allen Wirfs-Brock <allen at wirfs-brock.com> wrote:

The draft is available at harmony:specification_drafts#january_20_2014_draft_rev_22

The HTML version is up at: people.mozilla.org/~jorendorff/es6-draft.html

As always, please file bug reports on github: jorendorff/es-spec-html/issues or just email me.

# Allen Wirfs-Brock (12 years ago)

big thanks,

We there any new styling anomalies that your converter initially barfed on. I'm still battling (two steps forward, one back) intermittent broken multi-level list functionality, so anything that stands out might be a clue.

# Jason Orendorff (12 years ago)

The script initially barfed on some list formatting, but it was clearly my fault, not the document's.

I did file bug 2429 on some styling anomalies, not sure that'll help: ecmascript#2429