Closure (computer programming): Difference between revisions

Revision as of 00:44, 4 January 2024

Revision as of 09:58, 4 January 2024

Line 6:

== History and etymology ==

The concept of closures was developed in the 1960s for the mechanical evaluation of expressions in the [[λ-calculus]] and was first fully implemented in 1970 as a language feature in the [[PAL (programming language)|PAL programming language]] to support lexically scoped [[first-class function]]s.<ref name=dat2012>{{cite conference |author-link=David A. Turner |first=David A. |last=Turner |year=2012 |url=http://www.cs.kent.ac.uk/people/staff/dat/tfp12/tfp12.pdf |title=Some History of Functional Programming Languages |book-title=International Symposium on Trends in Functional Programming |pages=1–20 See 12 §2, note 8 for the claim about M-expressions. |publisher=Springer |doi=10.1007/978-3-642-40447-4_1 |isbn=978-3-642-40447-4 |series=Lecture Notes in Computer Science |volume=7829}}</ref>

[[Peter 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.<ref name=landin>

{{cite journal |last=Landin |first=P.J. |author-link=Peter Landin |title=The mechanical evaluation of expressions |journal=The Computer Journal |volume=6 |issue=4 |date=January 1964 |pages=308–320 |doi=10.1093/comjnl/6.4.308 |url=https://academic.oup.com/comjnl/article-pdf/6/4/308/1067901/6-4-308.pdf }}</ref> [[Joel Moses]] credits Landin with introducing the term ''closure'' to refer to a [[Anonymous function|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.<ref>

{{cite journal |last=Moses |first=Joel |author-link=Joel Moses |date=June 1970 |title=The Function of FUNCTION in LISP, or Why the FUNARG Problem Should Be Called the Environment Problem |journal=ACM Sigsam Bulletin |issue=15 |pages=13–27 |doi=10.1145/1093410.1093411 |id=[[AI Memo]] 199 |quote=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 1.5|LISP]] and [[ISWIM]]'s Lambda Closures.|hdl=1721.1/5854|s2cid=17514262 }}</ref><ref>{{cite book |last=Wikström |first=Åke |year=1987 |title=Functional Programming using Standard ML |publisher=Prentice Hall |isbn=0-13-331968-7 |quote=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.}}</ref> This use was subsequently adopted by [[Gerald Jay Sussman|Sussman]] and [[Guy L. Steele Jr.|Steele]] when they defined [[Scheme (programming language)|Scheme]] in 1975,<ref>{{cite report |last1=Sussman |first1=Gerald Jay |author1-link=Gerald Jay Sussman |last2=Steele |first2=Guy L. Jr. |author2-link=Guy L. Steele Jr. |date=December 1975 |title=Scheme: An Interpreter for the Extended Lambda Calculus |id=[[AI Memo]] 349}}</ref> a lexically scoped variant of [[Lisp (programming language)|Lisp]], and became widespread.

Sussman and [[Harold Abelson|Abelson]] also use the term ''closure'' in the 1980s with a second, unrelated meaning: the property of an operator that adds data to a [[data structure]] to also be able to add nested data structures. This use of the term comes from [[Closure (mathematics)|mathematics use]], rather than the prior use in computer science. The authors consider this overlap in terminology to be "unfortunate."<ref>{{cite book |last1=Abelson |first1=Harold |author1-link=Harold Abelson |last2=Sussman |first2=Gerald Jay |author2-link=Gerald Jay Sussman |last3=Sussman |first3=Julie |author3-link=Julie Sussman |date=1996 |title=Structure and Interpretation of Computer Programs |url=https://mitpress.mit.edu/sites/default/files/sicp/full-text/book/book.html |publisher=MIT Press |pages=98–99 |isbn=0-262-51087-1}}</ref>

Line 153:

A language implementation cannot easily support full closures if its run-time memory model allocates all [[automatic variable]]s on a linear [[Stack-based memory allocation|stack]]. In such languages, a function's automatic 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, typically via [[heap allocation]], rather than on the stack, and their lifetime must be managed so they survive until all closures referencing them are no longer in use.

This explains why, typically, languages that natively support closures also use [[Garbage collection (computer science)|garbage collection]]. 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 pointer]]s to freed automatic variables, as in lambda expressions in C++11<ref>''[http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2550.pdf Lambda Expressions and Closures]'' C++ Standards Committee. 29 February 2008.</ref> or nested functions in GNU C.<ref>{{cite web |work=GCC Manual, [|url=https://gcc.gnu.org/onlinedocs/gcc/Nested-Functions.html |title=6.4 Nested Functions], "|quote=If you try to call the nested function through its address after the containing function exits, all hell breaks loose. If you try to call it after a containing scope level exits, and if it refers to some of the variables that are no longer in scope, you may be lucky, but it's not wise to take the risk. If, however, the nested function does not refer to anything that has gone out of scope, you should be safe."}}</ref> 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 (programming language)|D]] version 1, it is assumed that the programmer knows what to do with [[delegation (programming)|delegates]] and automatic local variables, as their references will be invalid after return from its definition scope (automatic 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 automatic 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 (programming language)|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.

Line 424:

Capturing of variables by reference can be emulated by using a <code>final</code> reference to a mutable container, for example, a single-element array. The local 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.

With the advent of Java 8's lambda expressions,<ref>{{cite web |url=http://docs.oracle.com/javase/tutorial/java/javaOO/lambdaexpressions.html |title=Lambda Expressions (|work=The Java Tutorials) }}</ref> the closure causes the above code to be executed as:

<syntaxhighlight lang="java">

Line 441:

Local classes are one of the types of [[inner class]] that are declared within the body of a method. Java also supports inner classes that are declared as ''non-static members'' of an enclosing class.<ref>

{{cite web |url=https://blogs.oracle.com/darcy/entry/nested_inner_member_and_top

|title=Nested, Inner, Member, and Top-Level Classes |work=Joseph D. Darcy's Oracle Weblog |date=July 2007|archive-url=https://web.archive.org/web/20160831172734/https://blogs.oracle.com/darcy/entry/nested_inner_member_and_top |archive-date=31 August 2016 }}</ref> They are normally referred to just as "inner classes".<ref>

{{cite web |url=httphttps://java.sun.com/docs/books/tutorial/java/javaOO/innerclasses.html

|title=Inner Class Example (|work=The Java Tutorials: Learning the Java Language: Classes and Objects)

}}</ref> These are defined in the body of the enclosing class and have full access to instance variables of the enclosing class. Due to their binding to these instance variables, an inner class may only be instantiated with an explicit binding to an instance of the enclosing class using a special syntax.<ref>

{{cite web |url=httphttps://java.sun.com/docs/books/tutorial/java/javaOO/nested.html

|title=Nested Classes (|work=The Java Tutorials: Learning the Java Language: Classes and Objects)

}}</ref>