New ES6 draft (Rev23) now available
This version has undergone major internal restyling and seems to be in good shape for driving to ES6 completion.
All of the algorithms lists have new internal styling. However, because of the nature of MS Word numbered lists, it is quite likely some some slipped past me where the algorithm steps don't start at 1. If you see any please report them as a new bug at bugs.ecmascript.org.
On Sun, Apr 6, 2014 at 1:41 PM, Allen Wirfs-Brock <allen at wirfs-brock.com> wrote:
The April 5, 2014 ECMAScript 6 Draft Specification (Rev23) is now available at harmony:specification_drafts#april_5_2014_draft_rev_23
The HTML version is up at: people.mozilla.org/~jorendorff/es6-draft.html
As always, this is generated by the script at jorendorff/es-spec-html and you could totally knock out some of those issues and make it better.
Thanks a lot Jason, would you mind double check after latest TC39 meeting no major changes has been left out these version?
Andrea, that was published before the meeting, so it's actually missing everything from the meeting. Allen will be publishing drafts more frequently from here on.
On 14-04-06 11:41 AM, Allen Wirfs-Brock wrote:
The April 5, 2014 ECMAScript 6 Draft Specification (Rev23) is now available at harmony:specification_drafts#april_5_2014_draft_rev_23
I just noticed something odd.
If you open up the PDFs for rev22 and rev23, and compare section 7.3.16 "GetPrototypeFromConstructor", you'll see that the sub-steps that used to be 5.{a,b,c} are now top-level steps {6,7,8}. It's pretty clear that this wasn't an intentional change, because now step 5 is an if-then with no consequent. To make matters worse, if you open up the PDF with change markup, you'll see that this change isn't called out at all. (The only marked change in the whole algorithm is a minor deletion in step 3.)
Also, the Note that used to follow the algorithm is now step 10 of the algorithm. I'm guessing this is also unintentional, though it's less obviously so. But it too has no change markup.
(I don't have MS Word, but if LibreOffice is anything to go by, these changes aren't marked in the Word document either.)
It's odd and somewhat worrying that algorithm steps can change their level seemingly spontaneously, and without any resultant change markup.
Allen, you did say that all the algorithms have new internal styling, but the only side-effect you mentioned was that some might not start at step 1.
Of course, I'll file a bug for this case, and any other I see, but (a) I'll probably miss some, and (b) this seems like something that I (or any other reviewer) shouldn't have to be doing -- shouldn't the spec-production process be more resistant to silent unintended changes?
On Thu, Apr 10, 2014 at 11:45 PM, Michael Dyck <jmdyck at ibiblio.org> wrote:
I just noticed something odd.
If you open up the PDFs for rev22 and rev23, and compare section 7.3.16 "GetPrototypeFromConstructor", you'll see that the sub-steps that used to be 5.{a,b,c} are now top-level steps {6,7,8}.
I found a similar case earlier today—only the opposite direction, a step was indented more than before—and filed the bug: ecmascript#2633
It's pretty clear that this wasn't an intentional change, because now step 5 is an if-then with no consequent.
The sequence 'then</li>' appears five times in es6-draft.html. All are
bugs. I filed: ecmascript#2634
Maybe others can think of quick ways to hunt for similar issues.
rev22 - people.mozilla.org/~jorendorff/es6-draft-rev-22.html
You can/should file this but Allen and I discusses the issue at the face to face and Allen assured me a new draft, hopefully fixed, will be published sooner.
On Apr 10, 2014, at 9:45 PM, Michael Dyck wrote:
On 14-04-06 11:41 AM, Allen Wirfs-Brock wrote:
The April 5, 2014 ECMAScript 6 Draft Specification (Rev23) is now available at harmony:specification_drafts#april_5_2014_draft_rev_23
I just noticed something odd.
If you open up the PDFs for rev22 and rev23, and compare section 7.3.16 "GetPrototypeFromConstructor", you'll see that the sub-steps that used to be 5.{a,b,c} are now top-level steps {6,7,8}. It's pretty clear that this wasn't an intentional change, because now step 5 is an if-then with no consequent. To make matters worse, if you open up the PDF with change markup, you'll see that this change isn't called out at all. (The only marked change in the whole algorithm is a minor deletion in step 3.)
Also, the Note that used to follow the algorithm is now step 10 of the algorithm. I'm guessing this is also unintentional, though it's less obviously so. But it too has no change markup.
(I don't have MS Word, but if LibreOffice is anything to go by, these changes aren't marked in the Word document either.)
The markup was generated after the fact by having Word compare clean copies of rev22 and rev23. Formatting change (which including numbering level changes) were intentionally not included in the markup as they are so numerous (and mostly reflect no meaning change) as to be useless.
In order to get with an internal Word limit relating to lists I had to reapply the list style of essentially all algorithms and there are no doubt a few bugs in the processes. The internal limit is on what Word calls a "numId". The limit is 2047 and we had been bumping against it for several editions. Rev23 uses about 1500 numIds (ie 75% of the limit) so we appear to be in pretty good shape through the completion of ES6. I don't foresee the need for another round of changes of this sort before final publication.
It's odd and somewhat worrying that algorithm steps can change their level seemingly spontaneously, and without any resultant change markup.
It's not really spontaneous and the exclusion from the markup is intentional. It is possible to generate markup that includes such formatting changes is anyone really things they can extract useful information form it.
Allen, you did say that all the algorithms have new internal styling, but the only side-effect you mentioned was that some might not start at step 1.
The starting number issue is the closest to being "spontaneous" (they really aren't, but sometimes it feels that way). Things like 7.3.16 is just an error on may part and are easily fixed when they are identified.
Of course, I'll file a bug for this case, and any other I see, but (a) I'll probably miss some, and (b) this seems like something that I (or any other reviewer) shouldn't have to be doing -- shouldn't the spec-production process be more resistant to silent unintended changes?
These are the result of the normal production process, but of one-time (hopefully) massive manual edits.
4.3.25 doesn't seem to have a title name in the HTML export. I'm assuming some sort of Word black magic is to blame?
wrong styling in the source document...fixed
The April 5, 2014 ECMAScript 6 Draft Specification (Rev23) is now available at harmony:specification_drafts#april_5_2014_draft_rev_23
Changes include:
The April 5, 2014 ECMAScript 6 Draft Specification (Rev23) is now available at http://wiki.ecmascript.org/doku.php?id=harmony:specification_drafts#april_5_2014_draft_rev_23 Changes include: • Math.clz32 replaces Number.prototype.clz • for (let;;) loops get a new scope per iteration • Added [Yield] grammar parameter to ArrowFunction (Bug 2504) • Added [Yield] grammar parameters for Function/Generator/Class Declarations • Added [GeneratorParameter]] parameter to ClassExpression • Clarified that certainly early errors don’t apply when processing parenthesized expression cover grammar bug 2506) • 11.1.2 clarified the distinction between ES whitespace and Unicode whitespace. Added note that some Unicode white space characters are intentionally • Fixed Symbol.prototype.toString Symbol.prototype.valueOf to work correctly when this value is a primitive string value • Lookahead let restrictions added: IterationStatement: for (LeftHandSideExpression of AssignmentExpression)... and for (LeftHandSideExpression in Expression)... • Lookahead grammar restriction to disambiguate: new super() • Reverted default for missing class constructor back to “constructor(...args) {super(...args)} because of bug 2491 • Refactored identifier syntax/semantics into IdentiferReference, BindingIdentifier, and LabelIdentifier motivated by need to allow unicode escapes in non-keyword yield identifiers • Tweaked ordinary call to allocate non-strict mode wrapper objects using callee’s Realm • Named %Loader%: Reflect.Loader • Named %Realm%: Reflect.Realm • Added Reflect.Loader.prototype.@@toStringTag property • Provide complete algorithmic definition for RegExp.prototype.replace and RegExp.prototype.search • corrected RegExpExec so it correctly translates the match state of full Unicode RegExps back to UTF-16 capture values and endIndex. • documented (Annex D) fix to ES5 bug that exposed array updates to integer conversions side-effects • Typed Array Indexing: All canonical string numeric values considered to be possible indexes rather than expando property keys, eliminated vestigial spec. language for readonly/frozen typed arrays. • Updated Annex B function in block legacy compatibly hack based upon Jan. meeting concensus • Updated Function.prototype.toMethod as per Jan. meeting. • Updated Promises as per Jan. meeting consensus • Switched to “ize” from secondary British “ise” spelling of “initialize” and other words. • Resolved bugs: 2598-2597, 2591, 2584-2583, 2581-2578, 2576, 2572-2567, 2563-2562, 2560-2559, 2555, 2552, 2549, 2546, 2525, 2522-2521, 2519-2517, 2515-2514, 2512-2506, 2504, 2501-2500, 2498, 2493-2491, 2489, 2486, 2484, 2482, 2479-2478, 2476-2473, 2471-2469, 2465, 2442-2439, 2435, 2427, 2419-2417, 2415-2413, 2410-2407, 2404-2403, 2398-2395, 2393, 2390, 2370, 2368-2367, 2363-2359, 2352, 2350, 2347, 2343-2342, 2338, 2335, 2331, 2329-2328, 2326-2325, 2322, 2295, 2266, 2256, 2239, 2209, 1910, 1790, 1734, 1483, 1475, 1413-1412, 1263, 1240, 1158, 913, 311, 222 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140406/7c9c83a1/attachment-0001.html>