4 ms·
This is a good example of the problem with saying "closure" rather than "lexical scope". What most people mean by "closure" is a single anonymous function with
by davidmathers 17y ago
This is a good example of the problem with saying "closure" rather than "lexical scope". What most people mean by "closure" is a single anonymous function with state attached. What you've done here is returned an anonymous object containing two named functions.
So, it's obviously a closure because x is being "closed over". But if we're being pedantic it's actually not a closure. It's a lexically scoped anonymous object. And a closure is just an anonymous function, no more no less. A function in a language with lexical scope.
- btilly 17y agoSorry, but your attempted pedantry betrays some fundamental misunderstandings. You claim that a closure is just an anonymous function, no more no less. But as http://en.wikipedia.org/wiki/Closure_%28computer_science%29 http://en.wikipedia.org/wiki/Closure_%28computer_science%29 points out, this is a common misunderstanding that arises because people are introduced to the concepts at the same time. But the concepts of closures and anonymous functions really are distinct. A closure is a function that closes over some lexical environment. Whether the function is named or not is irrelevant. In JavaScript if I type foo = some_function_that_returns_a_closure(); then foo winds up being a named function, but it is still a closure. Most languages require more gyrations to wind up with a named function. But dynamic languages that allow metaprogramming at run-time usually have some way to make a closure into a named function. For example: ; Scheme (define foo some_closure) # Perl *foo = $some_closure; ; Common Lisp (setf (symbol-function ’foo) #’some-closure) Going the other way, anonymous functions are not always closures. What if you create an anonymous function outside of any lexical scope, it isn't a closure. What if you create an anonymous function in a language without the idea of lexical scope? Such languages exist. You can play with function pointers in C, anonymous functions in elisp (the Lisp built into emacs), and anonymous functions in vimsh (the scripting language built into vim) all you want but you won't get closures in those languages. Now back to my example. I returned a data structure that had two closures that closed over the exact same lexical scope. The functions foo.set, foo.get, bar.set and bar.get are all closures. Since pairs of them share environments they can communicate through those environments. But the fact that they appear in a more complex data structure doesn't change the fact that they are closures. If you prefer you can pull them out into variables and manipulate them that way: var foo_set = foo.set; var foo_get = foo.get; // time passes foo_set("hello"); alert(foo_get()); See? Closures! Don't be confused by the fact that JavaScript built an object system on top of data structures with closures. That detail is a red herring. Anyways you've got data structures with cooperating closures, anyone can build object systems. It is easier than you might think, as pg demonstrated nicely in his book On Lisp. (In section 25.2 he implements a reasonable object system in just 2 pages of code.) And the people at Netscape who invented JavaScript had been around Lisp enough that doing so was a natural step for them. The moral is that what matters are the mechanic Any function that has variables bound to a lexical scope is a closure. No matter what context it appears in. Whether it is named, part of an object, some other data structure, etc, it is still a closure.