Opinion

In this chapter, we take a closer look at how the ECMAScript language specification handles variables.
4.1 Environment: data structure for managing variables
An environment is the data structure that the ECMAScript specification uses to manage variables. It is a dictionary whose keys are variable names and whose values are the values of those variables. Each scope has its associated environment. Environments must be able to support the following phenomena related to variables:

  • Recursion
  • Nested scopes
  • Closures

Well use examples to illustrate how that is done for each phenomenon.
4.2 Recursion via environments
Well tackle recursion first. Consider the following code:
functionf(x) {return x *2;}functiong(y) {const tmp = y +1;return f(tmp);}assert.equal(g(3),8);
For each function call, you need fresh storage space for the variables (parameters and local variables) of the called function. This is managed via a stack of so-called execution contexts, which are references to environments (for the purpose of this chapter). Environments themselves are stored on the heap. That is necessary because they occasionally live on after execution has left their scopes (well see that when exploring closures). Therefore, they themselves cant be managed via a stack.
4.2.1 Executing the code
While executing the code, we make the following pauses:
functionf(x) {// Pause 3return x *2;}functiong(y) {const tmp = y +1;// Pause 2return f(tmp);}// Pause 1assert.equal(g(3),8);
This is what happens:

  • Pause 1 before calling g() (fig. 1).
  • Pause 2 while executing g() (fig. 2).
  • Pause 3 while executing f() (fig. 3).
  • Remaining steps: Every time there is a return, one execution context is removed from the stack.

Figure 1: Recursion, pause 1 before calling g(): The execution context stack has one entry, which points to the top-level environment. In that environment, there are two entries; one for f() and one for g().
Figure 2: Recursion, pause 2 while executing g(): The top of the execution context stack points to the environment that was created for g(). That environment contains entries for the argument y and for the local variable tmp.
Figure 3: Recursion, pause 3 while executing f(): The top execution context now points to the environment for f().
4.3 Nested scopes via environments
We use the following code to explore how nested scopes are implemented via environments.
functionf(x) {function square() {const result = x * x;return result; }return square();}assert.equal(f(6),36);
Here, we have three nested scopes: The top-level scope, the scope of f(), and the scope of square(). Observations:

  • The scopes are connected. An inner scope inherits all the variables of an outer scope (minus the ones it shadows).
  • Nesting scopes as a mechanism is independent of recursion. The latter is best managed by a stack of independent environments. The former is a relationship that each environment has with the environment in which it is created.

Therefore, the environment of each scope points to the environment of the surrounding scope via a field called outer. When we are looking up the value of a variable, we first search for its name in the current environment, then in the outer environment, then in the outer environments outer environment, etc. The whole chain of outer environments contains all variables that can currently be accessed (minus shadowed variables).
When you make a function call, you create a new environment. The outer environment of that environment is the environment in which the function was created. To help set up the field outer of environments created via function calls, each function has an internal property named [[Scope]] that points to its birth environment.
4.3.1 Executing the code
These are the pauses we are making while executing the code:
functionf(x) {function square() {const result = x * x;// Pause 3return result; }// Pause 2return square();}// Pause 1assert.equal(f(6),36);
This is what happens:

  • Pause 1 before calling f() (fig. 4).
  • Pause 2 while executing f() (fig. 5).
  • Pause 3 while executing square() (fig. 6).
  • After that, return statements pop execution entries off the stack.

Figure 4: Nested scopes, pause 1 before calling f(): The top-level environment has a single entry, for f(). The birth environment of f() is the top-level environment. Therefore, fs [[Scope]] points to it.
Figure 5: Nested scopes, pause 2 while executing f(): There is now an environment for the function call f(6). The outer environment of that environment is the birth environment of f() (the top-level environment at index 0). We can see that the field outer was set to the value of fs [[Scope]]. Furthermore, the [[Scope]] of the new function square() is the environment that was just created.
Figure 6: Nested scopes, pause 3 while executing square(): The previous pattern was repeated: the outer of the most recent environment was set up via the [[Scope]] of the function that we just called. The chain of scopes created via outer, contains all variables that are active right now. For example, we can access result, square, and f if we want to. Environments reflect two aspects of variables. First, the chain of outer environments reflects the nested static scopes. Second, the stack of execution contexts reflects what function calls were made, dynamically.
4.4 Closures and environments
To see how environments are used to implement closures, we are using the following example:
functionadd(x) {return (y) => { // (A)return x + y; };}assert.equal(add(3)(1),4);// (B)
What is going on here? add() is a function that returns a function. When we make the nested function call add(3)(1) in line B, the first parameter is for add(), the second parameter is for the function it returns. This works because the function created in line A does not lose the connection to its birth scope when it leaves that scope. The associated environment is kept alive by that connection and the function still has access to variable x in that environment (x is free inside the function).
This nested way of calling add() has an advantage: if you only make the first function call, you get a version of add() whose parameter x is already filled in:
const plus2 = add(2);assert.equal(plus2(5),7);
Converting a function with two parameters into two nested functions with one parameter each, is called currying. add() is a curried function.
Only filling in some of the parameters of a function is called partial application (the function has not been fully applied yet). Method .bind() of functions performs partial application. In the previous example, we can see that partial application is simple if a function is curried.
4.4.0.1 Executing the code
As we are executing the following code, we are making three pauses:
functionadd(x) {return (y) => {// Pause 3: plus2(5)return x + y; };// Pause 1: add(2)}const plus2 = add(2);// Pause 2assert.equal(plus2(5),7);
This is what happens:

  • Pause 1 during the execution of add(2) (fig. 7).
  • Pause 2 after the execution of add(2) (fig. 8).
  • Pause 3 while executing plus2(5) (fig. 9).

Figure 7: Closures, pause 1 during the execution of add(2): We can see that the function returned by add() already exists (see bottom right corner) and that it points to its birth environment via its internal property [[Scope]]. Note that plus2 is still in its temporal dead zone and uninitialized.
Figure 8: Closures, pause 2 after the execution of add(2): plus2 now points to the function returned by add(2). That function keeps its birth environment (the environment of add(2)) alive via its [[Scope]].
Figure 9: Closures, pause 3 while executing plus2(5): The [[Scope]] of plus2 is used to set up the outer of the new environment. Thats how the current function gets access to x.