≡ Menu

Announcing ECMAScript 5.1

ECMASCript 5.1 SpecificationThe 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.

  • Dmitry A. Soshnikov December 16, 2010, 3:04 am

    Hi Allen,

    From what I can see, a small err isn’t corrected in 10.6:

    an arguments object is created unless (as specified in 10.5) the identifier arguments occurs as an Identifier in the function’s FormalParameterList or occurs as the Identifier of a VariableDeclaration or FunctionDeclaration contained in the function code

    Though, but 10.5 (correctly) variables declarations do not disturb the already existing arguments object.

    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 mode eval cannot create a binding and evaluates in its sandbox environment.

    Dmitry.

    • allen December 20, 2010, 9:58 am

      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?

      • Dmitry A. Soshnikov December 23, 2010, 4:00 am

        In cases like this, the algorithm should be considered normative.

        Yes, this is a just a typo. Should it be fixed in ISO version?

        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?

        Exactly. The thing is that on one hand, 10.4.2.1 Strict Mode Restrictions says that eval is 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 eval is handled at the first step of the 10.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, eval still 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 eval means.

        I think the lack is exactly in order of the 10.4.2. Probably, the step which states that eval should create its own sandbox environment should go before the handling of indirect eval.

        Dmitry.

        • allen December 30, 2010, 10:32 am

          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.

          • Dmitry A. Soshnikov February 18, 2011, 12:54 am

            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.

  • Michael(tm) Smith December 29, 2010, 2:11 am

    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).” ?

    • allen December 30, 2010, 10:12 am

      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.

  • Michael(tm) Smith December 29, 2010, 5:29 pm

    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).

    • Michael(tm) Smith December 29, 2010, 5:46 pm

      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.

      • Michael(tm) Smith December 29, 2010, 6:16 pm

        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

  • Michael(tm) Smith December 29, 2010, 6:04 pm

    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

  • allen December 30, 2010, 10:02 am

    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.