In computer science, a closure is a function that is evaluated in an environment containing one or more bound variables. When called, the function can access these variables. The explicit use of closures is associated with functional programming and with languages such as ML and Lisp. Constructs such as objects in other languages can also be modeled with closures.

In some languages, a closure may occur when a function is defined within another function, and the inner function refers to local variables of the outer function. At runtime, when the outer function executes, a closure is formed, consisting of the inner function’s code and references to any variables of the outer function required by the closure.

A closure can be used to associate a function with a set of "private" variables, which persist over several invocations of the function. The scope of the variable encompasses only the closed-over function, so it cannot be accessed from other program code. However, the variable is of indefinite extent, so a value established in one invocation remains available in the next. As a consequence, closures can be used to hide state, and thus to implement object-oriented programming.

The term closure is often mistakenly used to mean anonymous function. This is probably because most languages implementing anonymous functions allow them to form closures and programmers are usually introduced to both concepts at the same time. These are however distinct concepts.

The concept of closures was developed in the 1960s and was first fully implemented as a language feature in the programming language Scheme. Since then, many languages have been designed to support closures.

Function objects are sometimes also called closures.

Closures and first-class functions

Closures typically appear in languages in which functions are first-class values—in other words, such languages allow functions to be passed as arguments, returned from function calls, bound to variable names, etc., just like simpler types such as strings and integers. For example, consider the following Scheme function:

; Return a list of all books with at least THRESHOLD copies sold.
(define (best-selling-books threshold)
  (filter 
    (lambda (book) (>= (book-sales book) threshold))
    book-list))

In this example, the lambda expression (lambda (book) (>= (book-sales book) threshold)) appears within the function best-selling-books. When the lambda expression is evaluated, Scheme creates a closure consisting of the code for the lambda and a reference to the threshold variable, which is a free variable inside the lambda.

The closure is then passed to the filter function, which calls it repeatedly to determine which books are to be added to the result list and which are to be discarded. Because the closure itself has a reference to threshold, it can use that variable each time filter calls it. The function filter itself might be defined in a completely separate file.

Here is the same example rewritten in ECMAScript (JavaScript), another popular language with support for closures:

// Return a list of all books with at least 'threshold' copies sold.
function bestSellingBooks(threshold) {
  return bookList.filter(
      function(book) { return book.sales >= threshold; }
    );
}

The function keyword is used here instead of lambda, and an Array.filter method ^[1] instead of a global filter function, but otherwise the structure and the effect of the code are the same.

A function may create a closure and return it. The following example is a function that returns a function.

In Scheme:

; Return a function that approximates the derivative of f
; using an interval of dx, which should be appropriately small.
(define (derivative f dx)
  (lambda (x) (/ (- (f (+ x dx)) (f x)) dx)))

In ECMAScript:

// Return a function that approximates the derivative of f
// using an interval of dx, which should be appropriately small.
function derivative(f, dx) {
  return function(x) {
    return (f(x + dx) - f(x)) / dx;
  };
}

Because the closure in this case outlives the scope of the function that creates it, the variables f and dx live on after the function derivative returns. In languages without closures, the lifetime of a local variable coincides with the execution of the scope where that variable is declared. In languages with closures, variables must continue to exist as long as any existing closures have references to them. This is most commonly implemented using some form of garbage collection.

While this is not always clarified, a closure need not be formed using an anonymous function. The Python programming language, for example, has very limited support for anonymous functions but fully supports closures. For example, one way the above ECMAScript example could be implemented in Python is:

# Return a function that approximates the derivative of f
# using an interval of dx, which should be appropriately small.
def derivative(f, dx):
    def gradient(x):
        return (f(x + dx) - f(x)) / dx
    return gradient

In this example, the function named gradient forms a closure together with the variables f and dx. This closure is then returned by the outer function named derivative. In fact, closures in Python must often be formed using named functions, where an anonymous function might be equally appropriate in other languages, because of the restrictions on lambda forms^[2].

Uses of closures

Closures have many uses:

• Designers of software libraries can allow users to customize behavior by passing closures as arguments to important functions. For example, a function that sorts values can accept a closure argument that compares the values to be sorted according to a user-defined criterion.
• Because closures delay evaluation—i.e., they do not "do" anything until they are called—they can be used to define control structures. For example, all Smalltalk's standard control structures, including branches (if/then/else) and loops (while and for), are defined using objects whose methods accept closures. Users can easily define their own control structures as well.
• Multiple functions can be produced which close over the same environment, enabling them to communicate privately by altering that environment (in languages that allow assignment).

In Scheme

(define foo #f)
(define bar #f)
 
(let ((secret-message "none"))
  (set! foo (lambda (msg) (set! secret-message msg)))
  (set! bar (lambda () secret-message)))
 
(display (bar)) ; prints "none"
(newline)
(foo "meet me by the docks at midnight")
(display (bar)) ; prints "meet me by the docks at midnight"

• Closures can be used to implement object systems [3].

Note: Some speakers call any data structure that binds a lexical environment a closure, but the term usually refers specifically to functions.

Differences in semantics

As different languages do not always have a common definition of the lexical environment, their definitions of closure may vary as well. The commonly held minimalist definition of the lexical environment defines it as a set of all bindings of variables in the scope, and that is also what closures in any language have to capture. It should be noted though that the meaning of a variable binding also differs. In imperative languages, variables bind to relative locations in memory that can store values. Although the relative location of a binding does not change at runtime, the value in the bound location can. In such languages, since closure captures the binding, any operation on the variable, whether done from the closure or not, is performed on the same relative memory location. Here is an example illustrating the concept in ECMAScript, which is one such language:

var f, g;
function foo()
{
  var x = 0;
  f = function() { return ++x; };
  g = function() { return --x; };
  x = 1;
  print(f()); // "2"
}
foo();
print(g()); // "1"
print(f()); // "2"

Note how function foo and the closures referred to by variables f and g all use the same relative memory location signified by local variable x.

On the other hand, many functional languages, such as ML, bind variables directly to values. In this case, since there is no way to change the value of the variable once it is bound, there is no need to share the state between closures - they just use the same values.

Yet another subset, lazy functional languages such as Haskell, bind variables to a result of a computation in the future. Consider this example in Haskell:

 
foo x y = let r = x / y
          in (\z -> z + r)
f = foo 1 0
main = do putStr (show (f 123))

The binding of r captured by the closure defined within function foo is to the computation (x / y) - which in this case results in division by zero. However, since it is the computation that is captured, and not the value, the error only manifests itself when the closure is invoked, and actually attempts to use the captured binding.

Yet more differences manifest themselves in the behavior of other lexically scoped constructs, such as return, break and continue statements. Such constructs can in general be considered in terms of invoking an escape continuation established by an enclosing control statement (in case of break and continue, such interpretation requires looping constructs to be considered in terms of recursive function calls). In some languages, such as ECMAScript, return refers to the continuation established by the closure lexically innermost with respect to the statement - thus, a return within a closure transfers control to the code that called it. In Smalltalk, however, the superficially similar ^ operator invokes the escape continuation established for the method invocation, ignoring the escape continuations of any intervening nested closures. The escape continuation of a particular closure can only be invoked in Smalltalk implicitly by reaching the end of the closure's code. The following examples in ECMAScript and Smalltalk highlight the difference:

"Smalltalk"
foo
  | xs |
  xs := #(1 2 3 4).
  xs do: [:x | ^x].
  ^0
bar
  Transcript show: (self foo) "prints 1"

// ECMAScript
function foo() {
  var xs = new Array(1, 2, 3, 4);
  xs.forEach(function(x) { return x; });
  return 0;
}
print(foo()); // prints 0

The above code snippets will behave differently because the Smalltalk ^ operator and the JavaScript return operator are not analogous. In the ECMAScript example, return x will leave the inner closure to begin a new iteration of the forEach loop, whereas in the Smalltalk example, ^x will abort the loop and return from the method foo.

Common Lisp provides a construct that can express either of the above actions: Smalltalk ^x behaves as (return-from foo x), while JavaScript return x behaves as (return-from nil x). Hence, Smalltalk makes it possible for a captured escape continuation to outlive the extent in which it can be successfully invoked. Consider:

foo
    ^[ :x | ^x ]
bar
    | f |
    f := self foo.
    f value: 123 "error!"

When the closure returned by the method foo is invoked, it attempts to return a value from the invocation of foo that created the closure. Since that call has already returned and the Smalltalk method invocation model does not follow the spaghetti stack discipline to allow multiple returns, this operation results in an error.

Some languages, such as Ruby, allow the programmer to choose the way he wants return to be captured. An example in Ruby:

# ruby
def foo
  f = Proc.new { return "return from foo from inside proc" }
  f.call # control leaves foo here
  return "return from foo"
end
 
def bar
  f = lambda { return "return from lambda" }
  f.call # control does not leave bar here
  return "return from bar"
end
 
puts foo # prints "return from foo from inside proc"
puts bar # prints "return from bar"

Both Proc.new and lambda in this example are ways to create a closure, but semantics of the closures thus created are different with respect to the return statement.

In Scheme, definition and scope of the return control statement is explicit (and only arbitrarily named 'return' for the sake of the example). The following is a direct translation of the Ruby sample.

(define call/cc call-with-current-continuation)
 
(define (foo)
  (call/cc 
   (lambda (return)
     (define (f) (return "return from foo from inside proc"))
     (f) ; control leaves foo here
     (return "return from foo"))))
 
(define (bar)
  (call/cc
   (lambda (return)
     (define (f) (call/cc (lambda (return) (return "return from lambda"))))
     (f) ; control does not leave bar here
     (return "return from bar"))))
 
(display (foo)) ; prints "return from foo from inside proc"
(newline)
(display (bar)) ; prints "return from bar"

Implementation and theory

Closures are typically implemented with a special data structure that contains a pointer to the function code, plus a representation of the function's lexical environment (e.g., the set of available variables and their values) at the time when the closure was created.

A language implementation cannot easily support full closures if its run-time memory model allocates all local variables on a linear stack. In such languages, a function's local variables are deallocated when the function returns. However, a closure requires that the free variables it references survive the enclosing function's execution. Therefore those variables must be allocated so that they persist until no longer needed. This explains why typically languages that natively support closures use garbage collection. The alternative is for the language to accept that certain use cases will lead to undefined behaviour, as in the proposal for lambda expressions in C++.^[1]

In ML, local variables are allocated on a linear stack. When a closure is created, it copies the values of those variables that are needed by the closure into the closure's data structure.

A typical modern Scheme implementation allocates local variables that might be used by closures dynamically and stores all other local variables on the stack.

Closures are closely related to Actors in the Actor model of concurrent computation where the values in the function's lexical environment are called acquaintances. An important issue for closures in concurrent programming languages is whether the variables in a closure can be updated and if so how these updates can be synchronized. Actors provide one solution.^[2]

See also

• Lambda calculus
• Funarg problem
• Continuation
• Spaghetti stack
• Value-level programming
• Command pattern
• Eiffel programming language
• Anonymous function
• Dependency injection
• Currying (a function)

References

1. ^ Lambda Expressions and Closures C++ Standards Committee. 29 February 2008.
2. ^ Foundations of Actor Semantics Will Clinger. MIT Mathematics Doctoral Dissertation. June 1981.

External links

• The Original "Lambda Papers": A classic series of papers by Guy Steele and Gerald Sussman discussing, among other things, the versatility of closures in the context of Scheme (where they appear as lambda expressions).
• Closures: An article about closures in dynamically-typed imperative languages, by Martin Fowler.
• Collection closure methods: example of a technical domain where using closures is convenient, by Martin Fowler.
• The beauty of closures: an article about using closures in Java and .NET