ECMA-262-3 in detail. Chapter 6. Closures.

Read this article in: Russian.

Introduction

In this article we will talk about one of the most discussed topics related to JavaScript — about closures. The topic, as a matter of fact, is not new and was discussed many times; there is a considerable quantity of articles devoted to this essence (some of them are very good, for example, article of Richard Cornford noted in the list of the additional literature), however we will try to discuss and understand it more from the theoretical point of view, and also will look on how closures are made in ECMAScript from within.

As I already mentioned in previous articles (and in comments to them), this articles are dependent on the previous parts. And if there is a necessity, for full understanding of this part, the chapter 4 (Scope chain), and, probably, related with it earlier article the chapter 2 (Variable object) are required to be read.

General theory

Before the discussion of closures directly in ECMAScript, it is necessary to specify a number of definitions from the general theory of functional programming (regardless ECMA-262-3 specification). As the examples explaining definitions, we will use, nevertheless, ECMAScript.

As is known, in functional languages (and ECMAScript supports this paradigm and stylistics), functions are the data, i.e. they can be kept in variables, passed as arguments to other functions, returned from functions etc. Such functions have special names and structure.

Definitions

Functional argument (“Funarg”) — is an argument which value is function.

Example:

function exampleFunc(funArg) {
  funArg();
}

exampleFunc(function () {
  alert('funArg');
});

The actual parameter related with the funarg in this case is the anonymous function, passed to exampleFunc function.

In turn, the function which has a functional argument is called as a functional or, is closer to mathematics, as an operator. In the example above, exampleFunc function is a functional.

As it has already been mentioned, function can be not only passed as an argument, but also returned as a value. The functions which return other functions are called as functions with functional value (function valued).

(function functionValued() {
  return function () {
    alert('returned function is called');
  };
})()();

Functional arguments, functionals and functions with functional value, are called as higher-order functions (HOF) or first-class functions (more generally as first-class objects). In ECMAScript all functions are first-class objects.

A functional which receives itself as an argument, is called as auto-applicative function (or self-applicative):

(function selfApplicative(funArg) {

  if (funArg && funArg === selfApplicative) {
    alert('self-applicative');
    return;
  }

  selfApplicative(selfApplicative);

})();

The function which returns itself is called as auto-replicative (or self-replicative) function. Sometimes, the name self-reproducing appears in the literature:

(function selfReplicative() {
  return selfReplicative;
})();

The variables defined in the functional argument, are of course accessible at activation of the funarg (because the variable object which stores the data of the context is created every time on entering the context):

function testFn(funArg) {

  // activation of the funarg, local
  // variable localVar is available
  funArg(10); // 20
  funArg(20); // 30

}

testFn(function (arg) {

  var localVar = 10;
  alert(arg + localVar);

});

However, as we know (in particular, from the chapter 4 of these articles), functions in ECMAScript can be enclosed and use variables from parent contexts. With this feature so-called a funarg problem is related.

Funarg problem

In stack-oriented programming languages local variables of functions are stored in a stack which is pushed with new elements every time at function activation. At return from a function these variables are being removed from a stack. Such model is the big restriction for using functions as functional values (i.e. returning them from parent functions). Mostly this problem appears when a function has free variables.

Free variable is a variable which is used by a function, but is neither parameter, nor local variable of this function.

Example:

function testFn() {

  var localVar = 10;

  function innerFn(innerParam) {
    alert(innerParam + localVar);
  }

  return innerFn;
}

var someFn = testFn();
someFn(20); // 30

In this case for the “innerFn” function, “localVar” is a free variable.

If this system would use a stack-oriented model for storing local variables, it would mean that on return from “testFn” function all its local variables would be removed from a stack. And that would cause an error by “innerFn” function activated via “someFn” variable from the outside. Moreover, in this particular case, in the stack-oriented implementation, return of “innerFn” function would be impossible, since “innerFn” is also a local for “testFn” and therefore is being removed on return from “testFn”.

Another problem of functional objects is related with passing a function as an argument in system with dynamic scope implementation.

Example (pseudo-code):

var z = 10;

function foo() {
  alert(z);
}

foo(); // 10 – with using both static and dynamic scope

(function () {

  var z = 20;
  foo(); // 10 – with static scope, 20 – with dynamic scope

})();

// the same with passing foo
// as an arguments

(function (funArg) {

  var z = 30;
  funArg(); // 10 – with static scope, 30 – with dynamic scope

})(foo);

We see that in systems with dynamic scope the variable (identifier) resolution is managed with a dynamic (active) stack of variables. Thus, free variables are searched in the dynamic chain of the current activation, but not in the static (lexical) scope chain which is saved at function creation. And this can lead to ambiguity. Thus, even if “z” will exist (in contrast with the previous example where local variables would be removed from a stack and therefore would not exist), there will be the question — which of “z” values (is more exact, “z” from which context, from which scope) should be used in various calls of “foo” function?

The described cases are two kinds of the funarg problem — depending on whether we deal with the functional value returned from a function (upward funarg), or with the functional argument passed to the function (downward funarg).

For solving this problem (and its subtypes) the concept of a closure was offered.

Closure

A closure, or is more complete, a lexical closure is a set of the code block and the data of the context in which this code block is created.

Example a pseudo-code:

var x = 20;

function foo() {
  alert(x); // free variable "x" == 20
}

// Closure for foo
fooClosure = {
  call: foo // reference to function
  lexicalEnvironment: {x: 20} // context for searching free variables
};

In the example above, “fooClosure” of course is a pseudo-code whereas in ECMAScript “foo” function already contains as one of its internal property a scope chain of a context in which it has been created.

The word “lexical” is often omitted, since it goes without saying, and in this case it focuses attention that at closure creation also the data of a context are saved. At next activations of that code block, free variables will be searched in this saved (closured) context, what we can see in examples above where the variable “z” always should be resolved to 10 in ECMAScript.

In definition we used the generalized concept — “the code block” but usually (and in ECMAScript) the term “function”, which we also will use, is used. However, not in all implementations closures are associated only with functions: for example, in Ruby programming language, as a closure a procedure object, a lambda-expression or a code block can be used.

As to implementations, for storage of local variables after the context is destroyed, the stack-based implementation is not fit any more (because it contradicts the definition of stack-based structure). Therefore, in this case as a rule, a closured lexical context is stored in the dynamic memory allocation (“heap”, so-called heap-based implementations), with using the garbage collector (GC) and references counting. Such systems are less effective on speed than stack-based systems. However, implementations can always make optimization: at parsing find out whether free variables, functional arguments or functional values are used in function and depending on it decide — whether to place the data in the stack or in the “heap”.

ECMAScript closures implementation

Having discussed the theory, we, at last, have reached the closures regarding directly to ECMAScript. Here it is necessary to notice that ECMAScript uses only static (lexical) scope (whereas in some languages, for example in Perl, variables can be declared using both static or dynamic scope).

var x = 10;

function foo() {
  alert(x);
}

(function (funArg) {

  var x = 20;

  // variable "x" for funArg is saved statically
  // from the (lexical) context, in which it was created
  // therefore:

  funArg(); // 10, but not 20

})(foo);

Technically, the data of lexical context which creates a function is saved in the internal [[Scope]] property of the function. If at this moment there are any ambiguities with the [[Scope]] property, I urgently recommend to return and read the chapter 4 devoted to the scope chain where the [[Scope]] property was discussed in detail. Indeed, if you completely understand the [[Scope]] and scope chain topics, the question on understanding of closures in ECMAScript will disappear by itself.

Referencing to algorithm of functions creation, we see that all functions in ECMAScript are closures as all of them, without an exception, at creation save scope chain of the current context (regardless, whether a function will be called or not — [[Scope]] has already been written to it at creation moment):

var x = 10;

function foo() {
  alert(x);
}

// foo is a closure
foo: <FunctionObject> = {
  [[Call]]: <code block of foo>,
  [[Scope]]: [
    global: {
      x: 10
    }
  ],
  ... // other properties
};

As it was mentioned above, for optimization reason when function does not use free variables, implementations can not store a lexical context in a function, but in standard ECMA-262-3 nothing is said about it; therefore, formally (and by the technical algorithm) — all functions save scope chain in the [[Scope]] property at creation moment.

Some implementations allow access to the closured context directly. For example in Rhino, for the [[Scope]] property of a function corresponds non-standard property __parent__ which we discussed in the chapter about variable object:

var global = this;
var x = 10;

var foo = (function () {

  var y = 20;

  return function () {
    alert(y);
  };

})();

foo(); // 20
alert(foo.__parent__.y); // 20

foo.__parent__.y = 30;
foo(); // 30

// we can move through the scope chain further to the top
alert(foo.__parent__.__parent__ === global); // true
alert(foo.__parent__.__parent__.x); // 10

One [[Scope]] value for “them all”

It is necessary to notice also that closured [[Scope]] in ECMAScript is the same object for the several closures created in one lexical context. It means that updating of the closured variable by one closure will affect at use of this variable by another closure:

var firstClosure;
var secondClosure;

function foo() {

  var x = 1;

  firstClosure = function () { return ++x; };
  secondClosure = function () { return --x; };

  x = 2; // affection on AO["x"], which is in [[Scope]] of both closures

  alert(firstClosure()); // 3, via firstClosure.[[Scope]]
}

foo();

alert(firstClosure()); // 4
alert(secondClosure()); // 3

The widespread mistake when create functions in a loop trying to associate with each of them a loop counter variable (expecting that each function will keep its “own” needed value) is related with this feature:

var data = [];

for (var k = 0; k < 3; k++) {
  data[k] = function () {
    alert(k);
  };
}

data[0](); // 3, but not 0
data[1](); // 3, but not 1
data[2](); // 3, but not 2

The previous example explains this behavior — a scope of a context which creates functions is one for that three functions (each function refers to it through the [[Scope]] property), and the variable “k” in this parent scope can be easily changed.

Schematically:

activeContext.Scope = [
  ... // higher variable objects
  {data: [...], k: 3} // activation object
];

data[0].[[Scope]] === Scope;
data[1].[[Scope]] === Scope;
data[2].[[Scope]] === Scope;

Accordingly, at the moment of function activations, last assigned value of “k” variable, i.e. 3 will be used.

To solve this issue creation of an additional enclosing context can be used:

var data = [];

for (var k = 0; k < 3; k++) {
  data[k] = (function _helper(x) {
    return function () {
      alert(x);
    };
  })(k); // pass "k" value
}

// now it is correct
data[0](); // 0
data[1](); // 1
data[2](); // 2

In this case, function “_helper” is created and activated with argument “k”. Returned value of “_helper” function is also a function, and exactly it is assigned to a corresponding element of the “data” array. This technique makes the following effect: being activated, “_helper” every time creates new activation object which has argument “x” and the value of this argument is the passed value of “k” variable. Thus, [[Scope]] of returned functions will be the following:

data[0].[[Scope]] === [
  ... // higher variable objects
  AO of the parent context: {data: [...], k: 3},
  AO of the _helper context: {x: 0}
];

data[1].[[Scope]] === [
  ... // higher variable objects
  AO of the parent context: {data: [...], k: 3},
  AO of the _helper context: {x: 1}
];

data[2].[[Scope]] === [
  ... // higher variable objects
  AO of the parent context: {data: [...], k: 3},
  AO of the _helper context: {x: 2}
];

We see that now [[Scope]] properties of functions have the reference to the needed value (via the “x” variable) and for this purpose we had to create additional activation object in the [[Scope]] (from the returned functions also of course it is possible to reference to “k” variable, with the same, correct for all functions value 3).

By the way, often, in various articles about JavaScript, as closures (incomplete) can be treated only showed above pattern (with creation of additional AO in [[Scope]] of created functions). From the practical viewpoint, in this case, really, only this pattern makes advantage, however, from the theoretical viewpoint as we already noted, all functions in ECMAScript are closures.

However, the described pattern is not a unique. To get the needed value of “k” variable is also possible, for example, using the following approach:

var data = [];

for (var k = 0; k < 3; k++) {
  (data[k] = function () {
    alert(arguments.callee.x);
  }).x = k; // save "k" as a property of the function
}

// also everything is correct
data[0](); // 0
data[1](); // 1
data[2](); // 2

Funarg and return

And one more feature is a return from closures. In ECMAScript, the return statement from a closure returns control flow to a calling context (a caller), whereas in other languages, for example in Ruby, various forms of closures processing return differently are possible in certain cases: it can be return to a caller, or in others cases — a full exit from an active context):

function getElement() {

  [1, 2, 3].forEach(function (element) {

    if (element % 2 == 0) {
      // return to "forEach" functional,
      // but not return from the getElement
      alert('found: ' + element); // found: 2
      return element;
    }

  });

  return null;
}
alert(getElement()); // null, but not 2

Theory versions

Often closures confuse or incorrectly treat (for some reason) only to anonymous functions. It is not so, as we saw — all functions (independently on their kind: anonymous, named, FE, FD), because of scope chain technique, are closures. An exception to this rule is that functions created via Function constructor have [[Scope]] property contains only global object. And for clarify this moment and to avoid messes, let’s separate two versions of closures theory in ECMAScript which can be used in discussions:

Closures in ECMAScript are:

• from the theoretical viewpoint: all functions since all of them save at creation and store their lexical context (and even in global function, the reference to a global variable is the reference to a free variable and that is why — the general scope chain mechanism is used);
• from the practical viewpoint: those functions are interesting which:
  • exist even if context in which they were created is already finished (e.g. are the functional values returned from function);
  • reference in a code to free variables.

Practical usage of closures

In practice closures allow to create elegant designs allowing customization of various calculations on a condition defined by a funarg. An example the .sort method of arrays which accepts as an argument the sort-condition function:

[1, 2, 3].sort(function (a, b) {
  ... // sort conditions
});

Or, for example, so-called, mapping functionals as the .map method of arrays (it is available not in all implementations, test e.g. in SpiderMonkey, since version 1.6) which map a new array on a condition of functional argument:

[1, 2, 3].map(function (element) {
  return element * 2;
}); // [2, 4, 6]

Often it is convenient to implement search functions with using functional arguments defining almost unlimited conditions for search:

someCollection.find(function (element) {
  return element.someProperty == 'searchCondition';
});

Also, we can note applying functionals as, for example, a .forEach method which applies funarg to array elements:

[1, 2, 3].forEach(function (element) {
  if (element % 2 != 0) {
    alert(element);
  }
}); // 1, 3

By the way, methods of function objects .apply and .call, also originate in applying functionals of functional programming. We already discussed these methods in a note about this value; here, we see them in a role of applying functionals — function is applied to arguments (to a list (an array) of arguments — in apply, and to positioned arguments — in call):

(function () {
  alert([].join.call(arguments, ';')); // 1;2;3
}).apply(this, [1, 2, 3]);

One more important application of closures are the deferred calls:

var a = 10;
setTimeout(function () {
  alert(a); // 10, after one second
}, 1000);

Also, callback functions:

...
var x = 10;
// only for example
xmlHttpRequestObject.onreadystatechange = function () {
  // callback, which will be called deferral ,
  // when data will be ready;
  // variable "x" here is available,
  // regardless that context in which,
  // it was created already finished
  alert(x); // 10
};
..

Creation of the encapsulated scope for the purpose of hiding auxiliary objects (initializing context):

var foo = {};

// initialization
(function (object) {

  var x = 10;

  object.getX = function _getX() {
    return x;
  };

})(foo);

alert(foo.getX()); // get closured "x" – 10

Conclusion

This article has turned out more about the general theory than about ECMA-262-3 specification, however, I think that this general theory has clarified some moments and allowed to get closer and in details to the concept of closures in ECMAScript. If you have questions, I will answer them with pleasure in comments.

Additional literature

• Javascript Closures (by Richard Cornford)
• Funarg problem
• Closures

Translated by: Dmitry A. Soshnikov.
Published on: 2010-02-28

Originally written by: Dmitry A. Soshnikov [ru, read »]
Originally published on: 2009-07-20 [ru]

Tags: Closure, ECMA-262-3, ECMAScript, First-class objects, Funarg, Functional programming

This entry was posted on February 28th, 2010 and is filed under ECMAScript. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response or Trackback from your own site.