Re: New ES6 spec draft (Rev 22, Jan 20, 2014)
On Mon, Jan 20, 2014 at 9:42 PM, Allen Wirfs-Brock al...@wirfs-brock.com wrote: The draft is available at http://wiki.ecmascript.org/doku.php?id=harmony:specification_drafts#january_20_2014_draft_rev_22 The HTML version is up at: http://people.mozilla.org/~jorendorff/es6-draft.html As always, *please* file bug reports on github: https://github.com/jorendorff/es-spec-html/issues or just email me. -j ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: New ES6 spec draft (Rev 22, Jan 20, 2014)
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. Allen On Jan 23, 2014, at 4:57 PM, Jason Orendorff wrote: On Mon, Jan 20, 2014 at 9:42 PM, Allen Wirfs-Brock al...@wirfs-brock.com wrote: The draft is available at http://wiki.ecmascript.org/doku.php?id=harmony:specification_drafts#january_20_2014_draft_rev_22 The HTML version is up at: http://people.mozilla.org/~jorendorff/es6-draft.html As always, *please* file bug reports on github: https://github.com/jorendorff/es-spec-html/issues or just email me. -j ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: New ES6 spec draft (Rev 22, Jan 20, 2014)
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: https://bugs.ecmascript.org/show_bug.cgi?id=2429 On Thu, Jan 23, 2014 at 7:23 PM, Allen Wirfs-Brock al...@wirfs-brock.com wrote: 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. Allen On Jan 23, 2014, at 4:57 PM, Jason Orendorff wrote: On Mon, Jan 20, 2014 at 9:42 PM, Allen Wirfs-Brock al...@wirfs-brock.com wrote: The draft is available at http://wiki.ecmascript.org/doku.php?id=harmony:specification_drafts#january_20_2014_draft_rev_22 The HTML version is up at: http://people.mozilla.org/~jorendorff/es6-draft.html As always, *please* file bug reports on github: https://github.com/jorendorff/es-spec-html/issues or just email me. -j ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: New ES6 spec draft (Rev 22, Jan 20, 2014)
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.
Cheers,
Tom
2014/1/21 Allen Wirfs-Brock al...@wirfs-brock.com
The draft is available at
http://wiki.ecmascript.org/doku.php?id=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.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: New ES6 spec draft (Rev 22, Jan 20, 2014)
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! ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: New ES6 spec draft (Rev 22, Jan 20, 2014)
On Tue, Jan 21, 2014 at 9:29 AM, Kevin Smith zenpars...@gmail.com wrote: 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... 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). Sam ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: New ES6 spec draft (Rev 22, Jan 20, 2014)
On Mon, Jan 20, 2014 at 7:42 PM, Allen Wirfs-Brock al...@wirfs-brock.comwrote: The draft is available at http://wiki.ecmascript.org/doku.php?id=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 We have been implementing module loading based on and giving feedback to https://github.com/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? jjb ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: New ES6 spec draft (Rev 22, Jan 20, 2014)
John, 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. Allen On Jan 21, 2014, at 7:43 AM, John Barton wrote: On Mon, Jan 20, 2014 at 7:42 PM, Allen Wirfs-Brock al...@wirfs-brock.com wrote: The draft is available at http://wiki.ecmascript.org/doku.php?id=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 We have been implementing module loading based on and giving feedback to https://github.com/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? jjb ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: New ES6 spec draft (Rev 22, Jan 20, 2014)
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. : ) ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
