Talk:Closure (computer programming)

message: In perl at least, a closure doesn't have to be a function definition. It's more or less anything between a pair of braces, that serves as it's own variable scope. In Damian Conway's Object Oriented Perl, I believe he uses closures to implement the private variables of an object, so it might be misleading to say that the closure itself is an object or acts like one. In any case, something needs to be said about scope here. Wesley
How could one use a closure that's not a function definition?
:Typically closures are not function definitions, they are anonymous functions. In Lisp, they are lambda functions, in Perl, they are blocks. —The preceding unsigned comment was added by Nowhere man (talk • contribs) 13:15, 7 March 2007 (UTC)
thread_title: Closures in Perl

message: I have just edited the page such that the Java simulation section has "final" instead of "immutable".  My understanding of the term immutable in the context of Java is that it means once you have a reference to the object its internal state will never change i.e. all fields (including private ones) can be declared final and all references that the object holds are themselves to immutable objects.  This property, as far as I know, is not detected or enforced by the runtime and is not necessary for a local variable to be used in an anonymous inner class.  The meaning of the keyword final, on the other hand, is that the value of the variable will never change which object it references (or will never change value if a primitive).  It is this that is necessary for the anonymous inner type to make use of the variable so that the runtime can simply clone the primitive values and object references of final variables on the stack when instantiating the anonymous inner class.
--Jwal 18:35, 12 Jun 2004 (UTC)
thread_title: Closures and Java

message: Python does not have closures and shouldn't even be listed among the list of languages that do have closures, let alone used as the example language to demonstrate what they are. Using Python to demonstrate what closures are is completely misleading and damaging to a reader's understanding of what closures are. Can we just swap the example language and remove Python from the list?  — Preceding unsigned comment added by Mmachenry (talk • contribs) 06:14, 25 June 2014 (UTC)
replies: text: Admittedly Python closures are broken in this respect compared to Scheme, but this is overstated.  As a matter of practice, 99% of the time Python closures work just like Scheme closures.  They look the same, work the same, and are used for the same purposes.  On the other hand, if you're using a closure in Python to hide modifiable state, it's probably a kindness that Python doesn't support what you want to do.  Jorend 20:41, 10 January 2006 (UTC)
replies: text: I have changed my view on this.  Python closures are not used for the same purposes as Scheme closures.  I am told that in Scheme, closures are very commonly used to hide state.  In Python, you would just use a class instead. Jorend 21:50, 15 February 2006 (UTC)

text: Your link to the discussion on the Python talk page seems to be broken, now -- the #Closures part of it, specifically.  It seems someone eliminated that part of the discussion. -- Apotheon 06:34, 22 November 2006 (UTC)
replies: text:  It's been archived over here.  --Piet Delport 09:31, 22 November 2006 (UTC)

text: Actually, you can get to the counter: the object returned by foo() is a function obj, it has an attribute ('func_closure' I think), which is a list of cell objects; one of those holds a reference to the list. There is another attribute func_code, which is a code object, it has an attribute which gives the corresponding names of the closure variables. So, it's not a direct access (and may change a bit in later Python versions) but it's plenty useful enough for debuggers and the like. The cell objects are used so that the outer function can change the variable after the inner function is created, and the closure will see the change; and they allow the outer function's frame to be destroyed while keeping the closure; the cells live as long as the outer frame or the inner function, whichever is later. There's no mechanical reason why closures could not change these shared variables -- the required opcode is there -- currently it is prevented by a syntactic catch-22 (any assignment to a name makes it local), but there was a decision made that only the outer function can change the binding. Remember that one invocation of the outer frame can manufacture any number of instances of the closure (each  with different parms), and any of these could be called recursively or re-entrantly in different threads, or they could call each other, and they all share the same cell from the original call to the outer function. Prohibiting them from shooting things out from under each other doesn't seem like a  bad idea, and you still have a way to share changeable state if you choose so to do.
This is largely an academic discussion; I'm not suggesting changes to the article. If Python's identity as a language supporting closures does come into question, however, maybe this will head it off. --Pgroce 14:26, 18 May 2006 (UTC)
thread_title: Closures and Python

message: Carl: thank you for clarifying that.
One query, though: I'm not sure if the actor model reference belongs under the heading "implementation"? ISTM that actors are related to more to abstractions than implementations. Also, the concurrency issue might deserve a section of its own, which could then also be expanded to cover the approaches taken in practice by languages like Erlang and Concurrent ML. I'll leave things unchanged myself till I've had a chance to read Clinger's thesis, though. Haeleth 15:49, August 22, 2005 (UTC)
:For now I changed the section title to "Implementation and Theory"--Carl Hewitt 16:53, 22 August 2005 (UTC)
thread_title: Implementation, actors, concurrency

message: It seems to me that the focus on "storing information" is just wrong.  Am I crazy?  Google says:
Definitions that do not mention storing information:    (--see function closure) (--see lambda) (--see lexical closure) .
Definitions that do mention storing information:  .
Definitions that sort of imply it: .
In my experience, a closure is (a) in source code, a syntactical construct where the code for a function appears, and it has open variables that are declared not within the function, but outside, in its lexical scope; (b) at run-time, the implementation of that function, consisting of some code and a pointer to the environment (where the open variables live at run-time).  You can assign to open variables in some languages, true; but a lot of functional languages don't let you assign to local variables at all; this is hardly the essential, defining feature of closures.  -- Jorend 21:13, 10 January 2006 (UTC)
thread_title:  Focus on state 

message: In "Closure-like constructs in other languages" section, I tried adding a non-breaking space so that "void *" would appear in the same line.  It worked fine in preview mode, but not in the actual article.  I know this is pretty minor, but still if someone with better understanding in HTML or Wiki can fix it that'd be great. madoka 09:25, 25 November 2006 (UTC)
thread_title:  Fix non-breaking space 

message: I rewrote the introduction based upon recent discussion and int19h's proposals. Please this is nothing more than a provisional attempt to articulate my own thoughts about closures and get some feedback from others. I have little invested in these specific words and I'm happy for this to be completely overhauled. However there are a few key aims that guided me that I do think are important:
# Start with the most general definition possible, one that allows for the idea that a closure may be more than simply binding the free variables of a functon.
# Quickly provide some basic characterization that can be understood with a minimal understanding of programming language.
# Keep the typical example because it captures the notion implied by many text book definitions of a closure.
# Defer more technical discussions of closures to a yet to be written Overview section. 
A B Carter (talk) 14:32, 4 February 2007 (UTC)
replies: text: Thanks for the comment. It means something since even after more than a month of research I still feel a bit wobbly about the concept. In this regards I'm still hoping to get a specific citation from you for "Lambda the Ultimate Imperative". Just which parts of the paper are directly relevant to what we've been talking about? A B Carter (talk) 18:04, 16 February 2007 (UTC)
thread_title:  Rewrite of Introduction 

message: There are way too many external references at bottom, listing most everyone's blog entry on "How to do closures in language X (and what are they)".  While a user of language X might want to know this, we should not try to anticipate every new programmer of every language.  They can use Google, or one of the sites intended as indexes of PL resources, for that.
Absent strong objections, I'll remove about 80% of the external links pretty soon. LotLE×talk 18:17, 21 July 2007 (UTC)
replies: text: I'm definitely in favor of also killing the "how to do it in language X" sections.  Does someone else want to do that? I'd feel like I was overstepping slightly since all I've done in this particular article is delete the linkfarm. LotLE×talk 15:18, 9 August 2007 (UTC)
thread_title:  Link farm 

message: I don't believe the cited article, taken in context, supports the statement that closures are a better alternative to objects.  It seems to say, instead, that closures and objects each have their appropriate place.  If there are no objections, I will remove the second half of the following statement: "Closures can be used to implement object systems [2], and may in fact be better alternatives to objects [3]."
--Akellymi (talk) 16:09, 19 February 2008 (UTC)
thread_title:  Closures and Objects 

message: What is a lexical enclosure? It should be mentioned in this article. Fresheneesz (talk) 18:42, 28 October 2008 (UTC)
thread_title:  lexical enclosure 

message: I think a small blurb about free variables is warranted.  The linked article heavily concerns mathematical free variables and only has one small out of the way line saying "oh by the way free variables in computer science are references to non local variables" and that line even has a citation needed marking.   My brain somehow parsed over that line and left me confused on the definition of closures for hours. 75.23.252.148 (talk) 02:40, 8 July 2009 (UTC)
thread_title:  Free variables. 

message: In the "Implementation and theory" section a sentence begins "In function languages with immutable data (like Erlang),...". Shouldn't this begin with "In functional languages with immutable data (like Erlang),..."? Or am I misunderstanding, and it is correctly missing the "al"? Whoever reads this and knows, please feel free to update it if necessary, as I don't know the subject very well. --Donkeydonkeydonkeydonkey (talk) 19:56, 23 July 2010 (UTC)
replies: text: Yup, tyop, fixed it, thanks. - 2/0 (cont.) 00:11, 24 July 2010 (UTC)
thread_title:  Small typo? (not sure) 

message: The example given is an example of closures in C, as amended by Apple's additions to the C language, and currently under review for inclusion in the C standard. It works in pure .c files under the gcc and clang, at least on Apple platforms. The only lines in the example that use Objective-C are the NSLog statements, which could be replaced with printf statements to have a pure C closure example. It is worth renaming (and repositioning up higher) the section "Closures in C (gcc, clang)" or somesuch.  —Preceding unsigned comment added by Hyperjeff (talk • contribs) 09:23, 18 September 2010 (UTC)
replies: text: I've expanded the section to refer to the fact it also applies to C and C++ in Mac. I don't think its should be moved higher or listed under C as it is a non-standard apple only extension.--Salix (talk): 10:04, 18 September 2010 (UTC)
thread_title:  Closures in Objective-C 

message: I came to this article because I have read statements like, "Language X has Closures," and "The Closure of function f is...," and "By line x, closure has occurred."  Is Closure a noun or a verb?  This article didn't clear it up at all, obviously, both, but then the first line of the abstract, treating it as a noun, keeps other parts of the abstract unclear.  Someone knowledgeable should clarify this, and all editors should keep this in mind.  (This is in no way a problem limited to this article alone.)  --Limited Atonement (talk) 18:07, 30 August 2011 (UTC)
replies: text: The act of "closing a function over its free variables" results in an object called "a closure". It's usually a noun, but can be used as a verb. I don't think this is a very uncommon phenomena? —Ruud 18:55, 30 August 2011 (UTC)
thread_title:  Clarify Part of Speech 

message: I think that the first example with function startAt(x) should explain from where the variable y comes and how it gets its value changed. This is implicitly told below the example by giving the result for closure1 & closure2, but a verbal explanation is missing.--Sae1962 (talk) 12:12, 5 February 2015 (UTC)
thread_title:  First example needs one more information 

message: Closures typically appear in languages in which functions are first-class values—in other words, such languages enable functions to be passed as arguments, returned from function calls, bound to variable names, etc., just like simpler types such as strings and integers. 
Earlier, it is indicated that 'c' is not such a language, and does not allow nested functions, but, in essence, via pointers, it does. You cannot expressly pass a function, but you can pass a pointer to a function, and this allows you to do some stuff that looks remarkably indistinguishable from those used in the examples of legitimate usage of closures.
I'm not arguing agains the claim, but suggesting that it would be good to discuss this somewhere as to how it differs.167.230.96.8 (talk) 20:04, 13 May 2015 (UTC)
replies: text: There is some discussion about this at First-class function#Non-local variables and closures. —Ruud 13:28, 14 May 2015 (UTC)
replies: text:  Nested functions, in this contaxt, means lexically nested functions. Last time I used C, gcc supported them while standard C didn't. (The next question is then whether such functions can be closures, i.e. use variables defined in their lexical environment when invoked outside of that scope.) Rp (talk) 12:27, 20 March 2018 (UTC)
thread_title:  Functions in C -- Clarity recommended... 

message: I'm not sure if I completely agree with these changes to the lead section. These changes allow for the possibility of a closure capturing variables by value instead of by reference. If feel this distinction is overly pedantic for the lead section, and makes it even harder to understand. Especially considering that the distinction only makes sense at all in imperative languages/language where variables are mutable, and even more so since C++ is the only language I'm aware of that allows capturing by value. Instead I'd suggest assuming immutable variables/capture-by-reference semantics in the lead and go into more detail on capture-by-value in a footnote and/or separate section on closures in imperative languages. —Ruud 15:08, 14 July 2016 (UTC)
thread_title:  Capture-by-value in the lead section 

message: Hi, these two seemed to me as typos but I'm not sure, and this is my first attempt to contribute to wp.. In Delegates (C#, D) section, the sentence "For example, the above code will not work correctly, because the variable a is on the stack, and after returning from test(),..." it is not clear to which function test() refers, test1(), test2() or both? And in the last sentence "The same is true for inner's class methods that..." should it be "inner" instead of "inner's class methods" or am I missing something? --S.POROY (talk) 19:45, 15 May 2017 (UTC)
thread_title:  Small typos or not? 

message: I was reading this article and found this mismatch in section "Lexical environment". There is no foo function nor f or g variables. I think the text is referring to the example in section "Anonymous functions". Example and text follows:
'use strict'
function makeFunc() {
  const name = "Closure";
  function displayName() {
    console.log(name);
  }
  return displayName;
};
const runFunc = makeFunc();
runFunc(); //Closure
Note how functionfoo and the closures referred to by variables f and g all use the same relative memory location signified by local variable x.
Bjacquet (talk) 11:59, 19 March 2018 (UTC)
thread_title:  Example and text don't match