The latest JavaScript language standard, ECMAScript 5, was approved by the Ecma International General Assembly one year ago. Since then it has seen rapid adoption in new browsers releases.
Once approved by Ecma, ES5 entered a process to become an ISO standard. That process should be completed in early 2011. The ISO edition of the ES5 specification incorporates a number of editorial and technical corrections including those listed in the current ES5 errata.
In order to keep the ISO and Ecma specifications in strict alignment TC39, the Ecma standards committee responsible for ECMAScript, has prepared a revision to the ES5 spec. whose content is identical to the ISO version. It also includes a new Annex F that lists the technically significant changes incorporated into the revision. This revision will be known as Ecma-262, Edition 5.1. We’ll probably just talk about it as ES5.1.
The final draft of the ES5.1 spec. is now available from the TC39 wiki.
Keep in mind that this is only a maintenance revision of the ES5 specification. It contains no new language or library features. TC39 is continuing its longer term work on “ECMAScript Harmony” which is intended to be the next version to include any new features.
(Note that I’m the project editor for the ES5 and ES5.1 specs.)
Comments on this entry are closed.
Hi Allen,
From what I can see, a small err isn’t corrected in 10.6:
Though, but 10.5 (correctly) variables declarations do not disturb the already existing
argumentsobject.From
10.4.2 Entering Eval Code— it’s still possible by the spec to create a binding in the enclosing (to the call) context, even if it’s said that in strict modeevalcannot create a binding and evaluates in its sandbox environment.Dmitry.
You’re correct, the introductory text to 10.6 is not as precise as the actual algorithm in 10.5 that calls 10.6. In cases like this, the algorithm should be considered normative.
I’m not sure what you specifically have in mind regarding 10.4.2. Are you saying that there is some specific place in the spec. where strict eval code can create a binding in the calling environment? Where?
Yes, this is a just a typo. Should it be fixed in ISO version?
Exactly. The thing is that on one hand,
10.4.2.1 Strict Mode Restrictionssays thatevalis strict:“…if either the code of the calling context or the eval code is strict code.”
I.e., either:
(function () {
“use strict”;
eval(…);
})();
or:
eval(“‘use strict’; …”);
On the other hand, since handling of the indirect
evalis handled at the first step of the10.4.2 Entering Eval Code, then the step 3 cannot affect. Thus we have, that even if we have the global strict code or the strict code of the calling function,evalstill able to create the binding of in the global environment:"use strict";
(function () {
"use strict";
("globalEval", eval)("var x = 10;");
})();
alert(x); // 10
Which contradicts the definition of what strict
evalmeans.I think the lack is exactly in order of the
10.4.2. Probably, the step which states thatevalshould create its own sandbox environment should go before the handling of indirecteval.Dmitry.
The algorithms are correct but the 10.4.2.1 quote should probably be: “… if the eval code is strict code or is called via a direct eval contained in strict code.”
An indirect eval called from strict code is strict only if the eval code explicit contains an “use strict;” directive. It does not “inherit” the strictness of its caller.
Every call is potentially an indirect eval call. If the strictness of indirect evals depended upon the strictness of the caller then we would have to pass the strictness of the caller through every call. That would require either an extra implicit parameter on every call or the ability to a callee to examine the call stack to to determine the strictness of its caller. We don’t want to force this on implementations.
Hi Allen,
(sorry for answering so long after that, but I reminded this case only after you recalled the indirect strictness scope on my blog; also there’s no mail notification from you blog that new answers appeared, so I didn’t see this explanation)
Yes, now I see the reason — it’s just a technical complexity to pass an additional flag.
Thanks for clarifications. Though, I additionally wrote to es-discuss — to get more audience which read it.
Dmitry.
Hi Allen,
Some comments after reading Annex F:
It seems that the text which reads “7.8.5: Missing ToBoolean restored in step 3.a.ii of second algorithm.” is meant to refer to 12.6.3 (The for Statement), not 7.8.5.
And I notice that step 3.a.ii of the *first* algorithm in 12.6.3 still has “If GetValue(testExprRef) is false, return (normal, V, empty).”
Shouldn’t that instead be “If ToBoolean(GetValue(testExprRef)) is false, return (normal, V, empty).” ?
Yes, you’re right about the missing ToBoolean in the first algorithm. However, the ISO/Ecma coordination rules are such that I may not be able to fix it. It may end of in the ES5.1 errata.
Another minor nit: I notice that Annex F lacks mention of the change that was made to 15.4.4.21 (documented in the 31 July 2010 errata).
I see that Annex F is also missing mention of the change made to 15.5.5.2 and recorded in the errata document. And perhaps some others — seems like the Annex F contents maybe need to be compared side-by-side with the errata document and anything that’s missing needs to be added from that.
I see now that Annex F does mention the 15.5.5.2 change, but incorrectly lists it as a change to 15.5.5.4
Annex F says “15.5.4.14: …. In step 13.a.iii.d, lengthA replaces A.length.” but its should say 13.c.iii.7.d
Generally Annex F doesn’t list editorial corrections that are unlikely to have any technical impact on implementations. The 15.4.4.21 correction falls into that category.
Thanks for the various typo corrections. I’m updating the draft to include them.