Closure (computer programming)
In computer science, a closure is a first-class function with free variables that are bound in the lexical environment. Such a function is said to be "closed over" its free variables. A closure is defined within the scope of its free variables, and the extent of those variables is at least as long as the lifetime of the closure itself. The explicit use of closures is associated with functional programming and with languages such as ML and Lisp. Closures are used to implement continuation passing style, and in this manner, hide state. Constructs such as objects and control structures can thus be implemented with closures.
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.
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; such variables are called the upvalues of the closure.
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. A closure retains a reference to the environment at the time it was created (for example, to the current value of a local variable in the enclosing scope) while a generic anonymous function need not do this.
Closures are closely related to function objects; the transformation from the former to the latter is known as defunctionalization or lambda lifting.
Etymology
Peter J. Landin defined the term closure in 1964 as having an environment part and a control part as used by his SECD machine for evaluating expressions.[1] Joel Moses credits Landin with introducing the term closure to refer to a lambda expression whose open bindings (free variables) have been closed by (or bound in) the lexical environment, resulting in a closed expression, or closure.[2][3] This usage was subsequently adopted by Sussman and Steele when they defined Scheme in 1975,[4] and became widespread.
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 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[5] 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, as in the following example:
// 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.
Closures and state representation
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.
In stateful languages, closures can thus be used to implement paradigms for state representation and information hiding, since the closure's upvalues (its closed-over variables) are of indefinite extent, so a value established in one invocation remains available in the next. Closures used in this way no longer have referential transparency, and are thus no longer pure functions; nevertheless, they are commonly used in "near-functional" languages such as Scheme.
Uses of closures
Closures have many uses:
- 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 also.
- In languages that allow assignment, multiple functions can be produced that close over the same environment, enabling them to communicate privately by altering that environment. 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"
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
Lexical environment
As different languages do not always have a common definition of the lexical environment, their definitions of closure may vary also. 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. However 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, are 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;
alert('inside foo, call to f(): ' + f()); // "2"
}
foo();
alert('call to g(): ' + g()); // "1"
alert('call to f(): ' + 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 results of future computations rather than values. Consider this example in Haskell:
foo :: Num -> Num -> (Num -> Num)
foo x y = let r = x / y
in (\z -> z + r)
f :: Num -> Num
f = foo 1 0
main = print (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.
Closure leaving
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 printString) "prints 1"
// ECMAScript
function foo() {
var xs = [1, 2, 3, 4];
xs.forEach(function (x) { return x; });
return 0;
}
alert(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 return
is 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 also 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++.[7] 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++. Similarly in D version 1, it is assumed that the programmer knows what to do with delegates and local variables, as their references will be invalid after return from its definition scope (local variables are on the stack) - this still permits many useful functional patterns, but for complex cases needs explicit heap allocation for variables. D version 2 solved this by detecting which variables must be stored on the heap, and performs automatically allocation. Because D uses garbage collection, in both versions, there is no need to track usage of variables as they are passed.
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. After a function returns, references are still valid. Heap cleaning is done by incremental garbage collector.
In ML, local variables are allocated on a linear stack [citation needed]. When a closure is created, it copies the values of those variables that are needed by the closure into the closure's data structure.
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. Closures are expressed naturally in Scheme. The lambda form encloses the code and the free variables of its environment, persists within the program as long as it can possibly be accessed, and can be used as freely as any other Scheme expression.
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.[8]
Closure-like constructs in other languages
In C, libraries that support callbacks sometimes allow a callback to be registered using two values: a function pointer and a separate void*
pointer to arbitrary data of the user's choice. Each time the library executes the callback function, it passes in the data pointer. This allows the callback to maintain state and to refer to information captured at the time it was registered. The idiom is similar to closures in functionality, but not in syntax.
Several object-oriented techniques and language features simulate some features of closures. For example:
Eiffel
Eiffel includes inline agents defining closures. An inline agent is an object representing a routine, defined by giving the code of the routine in-line. For example, in
ok_button.click_event.subscribe (
agent (x, y: INTEGER) do
map.country_at_coordinates (x, y).display
end
)
the argument to subscribe
is an agent, representing a procedure with two arguments; the procedure finds the country at the corresponding coordinates and displays it. The whole agent is "subscribed" to the event type click_event
for a
certain button, so that whenever an instance of the event type occurs on that button - because a user has clicked the button - the procedure will be executed with the mouse coordinates being passed as arguments for x and y.
The main limitation of Eiffel agents, which distinguishes them from true closures, is that they cannot reference local variables from enclosing scope, but this can easily be worked around by providing additional closed operands to the agent. Only Current (a reference to current object, analogous to this in Java), its features, and arguments of the agent itself can be accessed from within the agent body.
Erlang
In Erlang, closures are supported simply using the keyword fun
(Erlang's name for anonymous function) with references to outer variables. Because Erlang is a functional language with immutable value passing semantics, it is both easy to construct closures, execute them, or manage memory. Implementation is done by hidden module-level functions with N+M arguments (N: number of closed outer variables; M: number of own arguments), which is also very simple (see Lambda lifting).
construct_filter(L) ->
Filter = fun (X) -> lists:member(X, L) end, % by using L in this fun,
Filter. % we construct closure
complex_filter(SmallListOfSearchedElements, BigListToBeSearched) ->
Filter = construct_filter(SmallListOfSearchedElements),
Result = lists:filter(Filter, BigListToBeSearched),
Result.
C++ (operator overloading)
C++ allows defining function objects by overloading operator()
. These objects behave somewhat like functions in a functional programming language. They may be created at runtime and may contain state, but they do not implicitly capture local variables as closures do. Two proposals to introduce C++ language support for closures (both proposals call them lambda functions) are being considered by the C++ Standards Committee[9][10]. The main difference between these proposals is that one stores a copy of all the local variables in a closure by default, and another stores references to original variables. Both provide functionality to override the default behavior. If some form of these proposals is accepted, one would be able to write
void foo(string myname) {
typedef vector<string> names;
int y;
names n;
// ...
names::iterator i =
find_if(
n.begin(),
n.end(),
[&](const string& s){return s != myname && s.size() > y;});
// 'i' is now either 'n.end()' or points to the first string in 'n'
// which is not equal to 'myname' and whose length is greater than 'y'
}
At least two C++ compilers, Visual C++ 2010 (known also as Visual C++ 10.0) and GCC-4.5, already support this notation.
C#
C# delegates support closure-like behaviour. For instance,
delegate int Adder(int augend);
Adder CreateAdder(int addend)
{
return delegate(int augend)
{
return addend + augend;
};
}
// ...
Adder addtwo = CreateAdder(2),
addthree = CreateAdder(3);
int ten = addtwo(8),
eleven = addthree(8);
D
Closures are implemented by delegates in D.
auto test1() {
int a = 7;
return delegate() { return a + 3; }; // anonymous delegate construction
}
auto test2() {
int a = 20;
int foo() { return a + 5; } // inner function
return &foo; // other way to constructing delegate
}
void bar() {
auto dg = test1();
dg(); // =10 // ok, test1.a is in a closure and still exists
dg = test2();
dg(); // =25 // ok, test2.a is in a closure and still exists
}
D version 1, have limited closure support. For example above code will not work correctly, as variable a is on the stack, and after returning from test() function it is no longer valid to use it (most probably calling foo via dg(), will return 'random' integer). This can be solved by explicitly allocating a on heap, or using structs or class to store all needed closed variables and construct proper delegate to its method implementing the same code. Closures which are passed to any other functions, when referenced values are still valid (for example calling other function with closure as parameter, without removing variable from stack), and useful for writing generic data processing code, so this limitation is rarely seen in practice.
This limitation was fixed in D version 2 - variable 'a' will be automatically allocated (even if it would be declared 'auto') on the heap because it is used in inner function, delegate for it is constructed and reference to this delegate escapes current scope (via assignment to dg or return). Any other local variables (or arguments) not referenced by delegates (transitively) or which delegate's do not escape current scope, are still located on the stack, which is simpler and faster than heap allocation. The same is for inner's class methods which references function's variables.
Delphi
Delphi includes support for closures implemented as anonymous methods since the 2009 release. They can be declared inline within another method, and capture references to local state. For example:
type
TCounter = reference to function: integer;
function MakeCounter: TCounter;
var
i: integer;
begin
i := 0;
result := function: integer
begin
inc(i);
result := i;
end;
end;
Calling MakeCounter will return a new anonymous method. Invoking it will return 1 the first time, 2 the second, and so on.
Perl
Anonymous functions in Perl become closures when they reference lexical variables defined in enclosing scopes.
sub number_of_bagels {
my $bagels = shift;
return sub { my $sub_arg = shift; return $sub_arg + $bagels; };
}
my $func = number_of_bagels(5);
print "I now have " . $func->(2) . " bagels!\n"; #I now have 7 bagels!
print "I now have " . $func->(10) . " bagels!\n"; #I now have 15 bagels!
PHP
In PHP, closures can be implemented as anonymous functions:
<?php
$greet = function($name)
{
printf("Hello %s\r\n", $name);
};
$greet('World');
$greet('PHP');
?>
Or they can be implemented truer to the closure definition by using the use
keyword which makes the calling environment available:
<?php
$foo = function () use (&$bar)
{
echo($bar);
}
$bar = "Hello, World!";
$foo();
?>
Python
Python has two types of closures: lambda expressions and named closures (functions declared inside of functions).
Lambda expressions look like lambda x: x+3. A two-argument equivalent is lambda x,y: x*y and a no-argument equivalent is lambda: foo(). These are limited (or "crippled") by the fact that the result of the lambda expression must be one expression rather than a statement. Thus, it is not possible to put a "for", "while", or "if" block in a lambda expression. (However, "for" loops can be simulated using a list comprehension, e.g. lambda x: [foo(y) for y in x], and "if" blocks can be simulated using conditional expressions, e.g. lambda x: foo(x) if x == 2 else bar(x).) The two can be combined using "if" modifiers on list comprehensions, e.g. lambda x: [foo(y) for y in x if y > 5].
The other type of closure is named closures, as shown in the following Python 3.1 example:
#tested on python 3.1
def outer():
y = 0
def inner():
nonlocal y
y += 1
return y
return inner
f = outer()
print(f(), f(), f()) #prints 1 2 3
The nested function declaration def inner() actually declares a closure and assigns it the name of "inner". These nested functions have the full power of closures, i.e. the lexical environment at the time the "def" expression is evaluated is captured and can be referenced or assigned to even after the enclosing function goes out of scope, as shown.
In Python, a def statement is like a special assignment statement for functions -- just like the assignment x = y binds x to the value y, def foo(): body binds the name foo to the code body[11]. The best way to conceive of how a nested function declaration works is to consider it to be equivalent to the creation of a closure followed by its assignment to a variable. For example, the following is what the above function might look like in a hypothetical extended Python language where lambda expressions are no longer "crippled":
# NOTE: The following is NOT valid Python code!
# It is pseudo-code using a Python-like syntax.
def outer():
y = 0
inner = lambda: (
nonlocal y
y += 1
return y
)
return inner
f = outer()
print(f(), f(), f()) #prints 1 2 3
Java
Java allows defining "anonymous classes" inside a method; an anonymous class may refer to names in lexically enclosing classes, or read-only variables (marked as final) in the lexically enclosing method.
class CalculationWindow extends JFrame {
private volatile int result;
...
public void calculateInSeparateThread(final URI uri) {
// The expression "new Runnable() { ... }" is an anonymous class.
new Thread(
new Runnable() {
void run() {
// It can read final local variables:
calculate(uri);
// It can access private fields of the enclosing class:
result = result + 10;
}
}
).start();
}
}
Some features of full closures can be emulated by using a final reference to a mutable container, for example, a single-element array. The inner class will not be able to change the value of the container reference itself, but it will be able to change the contents of the container.
According to a Java 7 proposal[12], closures will allow the above code to be executed as:
class CalculationWindow extends JFrame {
private volatile int result;
...
public void calculateInSeparateThread(final URI uri) {
// the code #(){ /* code */ } is a closure
new Thread(#(){
calculate( uri );
result = result + 10;
}).start();
}
}
Java also supports another form of classes, which are called inner (or nested) classes.[13][14] These are defined in the body of an enclosing class and have full access to each and every instance variable of the enclosing class, thus resembling standard function closures. Due to their binding to these instance variables, a nested inner class may only be instantiated with an explicit binding to an instance of the enclosing class using a special syntax.
public class EnclosingClass {
/* Define the inner class */
public class InnerClass {
public int incrementAndReturnCounter() {
return counter++;
}
}
private int counter;
{
counter = 0;
}
public int getCounter() {
return counter;
}
public static void main(String[] args) {
EnclosingClass enclosingClassInstance = new EnclosingClass();
/* Instantiate the inner class, with binding to the instance */
EnclosingClass.InnerClass innerClassInstance =
enclosingClassInstance.new InnerClass();
for(int i = enclosingClassInstance.getCounter(); (i =
innerClassInstance.incrementAndReturnCounter()) < 10;) {
System.out.println(i);
}
}
}
Upon execution, this will print the integers from 0 to 9. Beware to not confuse this type of class with the so called static inner class, which is declared in the same way with an accompanied usage of the "static" modifier; those have not the desired effect but are instead just classes with no special binding defined in an enclosing class.
There have been a number of proposals for adding more fully-featured closures to Java[15][16][17].
C, C++, Objective-C 2.0 (blocks)
Apple introduced Blocks, a form of closure, into C, C++, Objective-C 2.0 and in Mac OS X 10.6 "Snow Leopard" and iOS 4.0. Closure variables are marked with __block
and pointers to block and block literals are marked with ^
.[18]
typedef int (^IntBlock)();
IntBlock downCounter(int start) {
__block int i = start;
return [[ ^int() {
return i--;
} copy] autorelease];
}
IntBlock f = downCounter(5);
NSLog(@"%d", f());
NSLog(@"%d", f());
NSLog(@"%d", f());
JavaScript
JavaScript or ECMAScript features closures also.
function countDownFrom (count) {
return function () {
return count--;
};
}
var countDownFromOne = countDownFrom(1);
var countDownFromTwo = countDownFrom(2);
// example uses console
// which may not be available depending on browser/environment;
// substitute accordingly (ie: with alert).
console.log(countDownFromOne());
//>1
console.log(countDownFromTwo());
//>2
console.log(countDownFromOne());
//>0
console.log(countDownFromTwo());
//>1
console.log(countDownFromTwo());
//>0
See also
- Anonymous function
- Blocks (C language extension)
- Command pattern
- Continuation
- Currying
- Funarg problem
- Lambda calculus
- Lazy evaluation
- Partial application
- Spaghetti stack
- Syntactic closure
- Value-level programming
References
- ^ P. J. Landin (1964), The mechanical evaluation of expressions
- ^ Joel Moses (1970), The Function of FUNCTION in LISP, or Why the FUNARG Problem Should Be Called the Environment Problem (PDF), AI Memo 199, retrieved 27 October 2009,
A useful metaphor for the difference between FUNCTION and QUOTE in LISP is to think of QUOTE as a porous or an open covering of the function since free variables escape to the current environment. FUNCTION acts as a closed or nonporous covering (hence the term "closure" used by Landin). Thus we talk of "open" Lambda expressions (functions in LISP are usually Lambda expressions) and "closed" Lambda expressions. [...] My interest in the environment problem began while Landin, who had a deep understanding of the problem, visited MIT during 1966-67. I then realized the correspondence between the FUNARG lists which are the results of the evaluation of "closed" Lambda expressions in LISP and ISWIM's Lambda Closures.
{{citation}}
: Unknown parameter|month=
ignored (help) - ^ Åke Wikström (1987). Functional Programming using Standard ML. ISBN 0-13-331968-7.
The reason it is called a "closure" is that an expression containing free variables is called an "open" expression, and by associating to it the bindings of its free variables, you close it.
- ^ Gerald Jay Sussman and Guy L. Steele, Jr. (1975), Scheme: An Interpreter for the Extended Lambda Calculus, AI Memo 349
{{citation}}
: Unknown parameter|month=
ignored (help) - ^ "array.filter". Mozilla Developer Center. 10 January 2010. Retrieved 9 February 2010.
- ^ "Re: FP, OO and relations. Does anyone trump the others?". 29 December 1999. Retrieved 23 December 2008.
- ^ Lambda Expressions and Closures C++ Standards Committee. 29 February 2008.
- ^ Foundations of Actor Semantics Will Clinger. MIT Mathematics Doctoral Dissertation. June 1981.
- ^ JTC1/SC22/WG21 - Papers 2006 mailing2006-02-pre-Berlin
- ^ A proposal to add lambda functions to the C++ standard
- ^ http://docs.python.org/reference/compound_stmts.html#function-definitions
- ^ "Java 7 Closure Draft Specification".
- ^ "Nested Classes (The Java Tutorials > Learning the Java Language > Classes and Objects)".
- ^ "Inner Class Example (The Java Tutorials > Learning the Java Language > Classes and Objects)".
- ^ http://www.javac.info/
- ^ http://docs.google.com/View?docid=k73_1ggr36h
- ^ http://docs.google.com/Doc?id=ddhp95vd_0f7mcns
- ^ Joachim Bengtsson (7 July 2010). "Programming with C Blocks On Apple Devices". Retrieved 18 September 2010.
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).
- Neal Gafter (28 January 2007). "A Definition of Closures".
- Gilad Bracha, Neal Gafter, James Gosling, Peter von der Ahé. "Closures for the Java Programming Language (v0.5)".
{{cite web}}
: CS1 maint: multiple names: authors list (link) - Closures: An article about closures in dynamically-typed imperative languages, by Martin Fowler.
- Collection closure methods: An example of a technical domain where using closures is convenient, by Martin Fowler.
- Javascript
- What are closures: A post on closures in Javascript.
- Javascript Closures for Dummies: An article teaching closures in Javascript by examples.
- Java and .NET
- The beauty of closures: An article about using closures in Java and .NET
- Delphi
- Nick Hodges, "Delphi 2009 Reviewers Guide", October 2008, CodeGear Developer Network, CodeGear.
- Craig Stuntz, "Understanding Anonymous Methods", October 2008
- Dr. Bob, "Delphi 2009 Anonymous Methods"
- Ruby
- Robert Sosinski, "Understanding Ruby Blocks, Procs and Lambdas", December 2008