Continuing woes in reading the ES6 spec language

Allen Wirfs-Brock allen at
Thu Sep 12 14:00:26 PDT 2013

On Sep 12, 2013, at 12:40 PM, Jason Orendorff wrote:

> Just as a worked example, answering Oliver's question about default
> expressions took me the better part of an hour.
> The default-expression h() in code like
>    function f(x=h(), y) {
>        function h() { ... }
>    }
> is evaluated in the scope of f, as I expected, so {x, h, y} are all in
> scope there.
> But I was surprised by the timing; h() is evaluated
> (a) before y is populated with the actual argument value;

yup, initialization happens left to right and binding are in their "temperal dead zone" untell they are initialized

> (b) before the arguments object is fully initialized.

I that that's a spec. bug. 

> That last surprise seems really unfortunate, since the expression can
> access the arguments object, observing it before and after
> CompleteMapped/StrictArgumentsObject, or even cause those to fail. Can
> we change that?

> It also means that we have to store actual arguments "somewhere else"
> while default-expressions are being evaluated, since the spec requires
> y to be undefined while the default-expression h() is being evaluated.
> Here are the steps (many are elided).
> - Start in Ordinary Function [[Call]] (thisArgument, argumentsList).
> - Step 8 or 9 creates localEnv (8 if we're calling an arrow function, 9
>  otherwise)
> - Steps 10-12 make localEnv the current scope
> - Step 13 calls Function Declaration Initialisation, passing
>  localEnv
> - Step 5 of that algorithm calls VarScopedDeclarations(code).
>  - 13.1.1 and 15.1.1 contain implementations of VarScopedDeclarations
>    and TopLevelVarScopedDeclarations.
>  - VarScopedDeclarations(code) returns a list of the top-level
>    VariableStatements and FunctionDeclarations in the function body.
>    Note that VariableStatements in blocks are not included. (A bug?)

doesn't matter, we're only us that list to filtering out top level function delclarations (step 91)

> - Step 8 creates bindings for nested functions.
> - Step 9 creates bindings for parameters. They're all undefined so far.
> - Step 11 creates a binding for "arguments".
> - Step 13 creates bindings for vars (not using the result of step 5,
>  but a different static semantic routine, VarDeclaredNames, which
>  I assumed, but did not check, is accurate for this purpose).
> - Step 15 creates bindings for let/const/class declarations.
> - Step 16 actually creates functions (in the scope of the new
>  environment) to populate each nested function binding created in step 8.
> - Steps 18-20 create the arguments object and populates the binding
>  created in step 11 .
Step 12?  At least in my draft.

But that binding isn't initialized until step 23.C which I think is a bug.  It's way prevents arguments from being reference in initializers. 

> - Step 21 does Binding Instantiation, which is defined in many places
>  but here we care about
>  - That invokes Indexed Binding Instantiation on the parts of the
>    FormalParameters, which is defined further down in
>  - Which ultimately performs Indexed Binding Initialisation for each
>    FormalParameter. (This call site is step 3 of the 8th algorithm in
>  - I wasn't able to find a definition for that, but syntactically
>    a FormalParameter is just a BindingElement, and Indexed Binding
> Initialization
>    is defined for those, in the 15th algorithm in
Exactly, the semantics for BindingElement apply.
It's important to apply the chain production semantics evaluation rule described 5.2 paragraph 4.
IndexedBindingInitialization(FormalParamter : BindingElement) = IndexedBindingInitialization(BindingElement)

>    - Step 6 of that says, if an Initialiser_opt (that is, a default
>      value expression) is present, and the value is undefined,
>      we evaluate the Initializer. Since it doesn't say anything
>      about in what scope, I assume it uses the current scope,
>      established way back at the beginning of this adventure.

up at the very top, "step 10-12 make localEnv the current scope"

> -j
> _______________________________________________
> es-discuss mailing list
> es-discuss at

More information about the es-discuss mailing list