[3] Joel Moses credits Landin with introducing the term closure to refer to a lambda expression with open bindings (free variables) that have been closed by (or bound in) the lexical environment, resulting in a closed expression, or closure.
[4][5] This use was subsequently adopted by Sussman and Steele when they defined Scheme in 1975,[6] a lexically scoped variant of Lisp, and became widespread.
Lastly, a closure is only distinct from a function with free variables when outside of the scope of the non-local variables, otherwise the defining environment and the execution environment coincide and there is nothing to distinguish these (static and dynamic binding cannot be distinguished because the names resolve to the same values).
Closures are also often used with callbacks, particularly for event handlers, such as in JavaScript, where they are used for interactions with a dynamic web page.
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.
These are analogous to private variables in object-oriented programming, and in fact closures are similar to stateful function objects (or functors) with a single call-operator method.
A language implementation cannot easily support full closures if its run-time memory model allocates all automatic variables on a linear stack.
However, a closure requires that the free variables it references survive the enclosing function's execution.
The alternatives are manual memory management of non-local variables (explicitly allocating on the heap and freeing when done), or, if using stack allocation, for the language to accept that certain use cases will lead to undefined behaviour, due to dangling pointers to freed automatic variables, as in lambda expressions in C++11[10] or nested functions in GNU C.[11] The funarg problem (or "functional argument" problem) describes the difficulty of implementing functions as first class objects in a stack-based programming language such as C or C++.
D version 2 solved this by detecting which variables must be stored on the heap, and performs automatic allocation.
In strict functional languages with immutable data (e.g. Erlang), it is very easy to implement automatic memory management (garbage collection), as there are no possible cycles in variables' references.
For example, in Erlang, all arguments and variables are allocated on the heap, but references to them are additionally stored on the stack.
Scheme, which has an ALGOL-like lexical scope system with dynamic variables and garbage collection, lacks a stack programming model and does not suffer from the limitations of stack-based languages.
The lambda form encloses the code, and the free variables of its environment persist within the program as long as they can possibly be accessed, and so they can be used as freely as any other Scheme expression.
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.
In imperative languages, variables bind to relative locations in memory that can store values.
Yet another subset, lazy functional languages such as Haskell, bind variables to results of future computations rather than values.
Consider this example in Haskell: 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.
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).
Hence, Smalltalk makes it possible for a captured escape continuation to outlive the extent in which it can be successfully invoked.
In Scheme, definition and scope of the return control statement is explicit (and only arbitrarily named 'return' for the sake of the example).
This enables the callback to maintain state and to refer to information captured at the time it was registered with the library.
The void* pointer is not type safe so this C idiom differs from type-safe closures in C#, Haskell or ML.
Callbacks are used extensively in graphical user interface (GUI) widget toolkits to implement event-driven programming by associating general functions of graphical widgets (menus, buttons, check boxes, sliders, spinners, etc.)
The next example is invalid because adder is a top-level definition (depending on compiler version, it could produce a correct result if compiled with no optimizing, i.e., at -O0): But moving adder (and, optionally, the typedef) in main makes it valid: If executed this now prints 11 as expected.
Apple introduced blocks, a form of closure, as a nonstandard extension into C, C++, Objective-C 2.0 and in Mac OS X 10.6 "Snow Leopard" and iOS 4.0.
They may be created at runtime and may contain state, but they do not implicitly capture local variables as closures do.
The main limitation of Eiffel agents, which distinguishes them from closures in other languages, is that they cannot reference local variables from the enclosing scope.
The values of the outer local variables can be passed by providing additional closed operands to the agent.