

Closures – A Simple Explanation (Using Ruby) - bleakgadfly
http://www.skorks.com/2010/05/closures-a-simple-explanation-using-ruby/

======
colanderman
"the most popular languages that are in use right now don't support closures (
_Java_ , C++)"

That is blatantly wrong. Closures, that is, the implementation structure which
stores along with a code pointer the references or values to which local
variables referenced by said code are bound, have been in Java since version
_1.0_. Otherwise you could not write code such as:

class foo { final static int bar = 6; static class baz { int bla() { return
bar; } } }

and expect "(new foo.baz()).bla()" to return 6.

What Java _is_ missing (and I suspect what the author is conflating closures
with) are _anonymous functions_ , which require closures to function properly
for the same reason inner classes require closures.

 _Closures are not anonymous functions._ Closures are an _implementation
detail_ which allow anonymous functions (among other structures) to act as
expected in statically-scoped languages.

Scheme has anonymous functions and closures.

Java does not have anonymous functions but _does_ have closures.

Emacs Lisp has anonymous functions but does _not_ have closures (and thus does
not exhibit static scope).

BASIC has neither anonymous functions nor closures.

(It is worthwhile to note that there are other methods for implementing static
scope such as alpha-renaming but they are usually much less efficient than
closures.)

~~~
tzs
What happens if bar is not final and/or not static?

~~~
spacemanaki
If it's not static you wouldn't be able to reference it from the static
context (the inner class baz). It could be non-final though, because it's a
field not a local.

The second part is the more interesting part, and is part of what people are
talking about when they say that Java doesn't have closures: you can't modify
closed over local (stack allocated) variables. However you can call methods
that modify or otherwise modify heap-allocated objects, for instance if bar
was an array you could modify it's contents, or if it was a Vector you could
call addElement() or whatever.

In the GP's case, bar is a member field, not a local, so I don't think it
needs to be final, and a quick test checks out. But if those were variables
local to a method and you referenced them from an anonymous inner class, they
would have to be final.

See:
[http://c2.com/ppr/wiki/JavaIdioms/ClosuresThatWorkAroundFina...](http://c2.com/ppr/wiki/JavaIdioms/ClosuresThatWorkAroundFinalLimitation.html)

If I recall correctly, from digging into the famous Guy Steele quote "we were
after the C++ programmers. We managed to drag a lot of them about halfway to
Lisp." I think this decision was made at the time because programmers didn't
like the idea of heap-allocated local primitives. I could be totally off base
here though. That wiki page mentions something about preserving the threading
model, which sounds reasonable, but I don't know enough about Java's history
to be totally clear on the motivation.

edited because I'm a pedant.

and the relevant message from Guy Steele:
[http://people.csail.mit.edu/gregs/ll1-discuss-archive-
html/m...](http://people.csail.mit.edu/gregs/ll1-discuss-archive-
html/msg04030.html) (that whole thread is fascinating, massive respect for GLS
as if I didn't already, and helped quell some of my hipster Java hatred.)

~~~
colanderman
Glad you know more about Java than I do :) I never knew about the restriction
on mutating local variables in the closure. It's strange to think about that
coming from the FP world where all mutable values are references to cells that
(conceptually) live on the heap.

------
enneff
From the succinct description of closures:

    
    
        It remembers the values of all the variables that were in
        scope when the function was created. It is then able to
        access those variables when it is called even though they may
        no longer be in scope.
    

No! It doesn't remember the _values_. It binds the _variables_. This is a
major misstep in describing closures. The most important point: when the
values of the bound variables change _the closure sees the new values_.

Please, fix this!

A better simple description of closures:

* You can pass a closure around as a value (to be called later).

* When you create a closure it is bound to the variables in its current scope. When you call a closure, it sees the _current_ value of the bound variables (not their values at the time the closure was created).

Follow this with a simple example, like:

    
    
        i := 0
        inc := func() {
            i++
        }
        println(i) // prints "0"
        inc()
        println(i) // prints "1"
        inc()
        println(i) // prints "2"

~~~
shasta
Depends on the language. "Closure" (at least to me) doesn't imply this bevaior
in a language with mutable variables. And then you have pure languages and
languages which only support mutation through reference values, in which his
explanation would be correct.

~~~
Jach
Indeed. Python is a prime example of a language with closures that doesn't do
variable-name binding, due to the way variables and specifically assignments
work in general with Python.

~~~
carbonica
I'm sorry? Python is the same way:

    
    
        >>> i = 10
        >>> def x():
        ...   print i
        ... 
        >>> x()
        10
        >>> i = 11
        >>> x()
        11
    

The value is not closed over in any language I can think of off the top of my
head. It's a reference to a variable in lexical scope.

What python does slightly differently is writing to variables in outer scopes.
But it still closes over references.

~~~
Jach
The writing to variables in outer scopes is what I meant by a lack of actual
name-binding, due to the way Python does assignments; it seems I expressed
that poorly. Here's a better attempt. The top poster's example simply doesn't
work in Python:

    
    
        >>> i = 0
        >>> def inc():
        ...   i += 1
        ...
        >>> print i
        0
        >>> inc()
        Traceback (most recent call last):
        File "<stdin>", line 1, in <module>
        File "<stdin>", line 2, in inc
        UnboundLocalError: local variable 'i' referenced before assignment
    

So variables are name-bound in the sense that you can read from their original
name and reference but you can't assign in normal ways. (Python has closures,
which I said, just not typical closures that other languages might have.)
Leading to the pattern of wrapping an array or dict or class around the thing
you're interested in.

    
    
        >>> i_wrapped = [0]
        >>> def inc():
        ...   i_wrapped[0] += 1
        ... 
        >>> print i_wrapped[0]
        0
        >>> inc()
        >>> print i_wrapped[0]
        1
    

One could argue that one shouldn't really have such mutable state inside a
closure of the enclosed items, which I do, but a person expecting to (set!) or
the like is going to be surprised.

Edit: I guess it should be said that Python 3 has the 'nonlocal' keyword, and
Python 2 has the 'global' keyword for global cases, which allows for expected
behavior. So the functionality is still there, but still needs an extra
statement.

    
    
        >>> i = 0
        >>> def out():
        ...   i = 0
        ...   def inc():
        ...     nonlocal i
        ...     i += 1
        ...   print(i)
        ...   inc()
        ...   print(i)
        ... 
        >>> print(i)
        0
        >>> out()
        0
        1
        >>> print(i)
        0

~~~
enneff
Python is a bad example here, as its scoping rules are inconsistent and
frequently surprising.

------
malkia
For me one of the coolest ways of using closures was to implement undo system.
It's not very efficient, but easy to write and compose.

Basically every editor operation can return a function that does the opposite.
For example (some lua-like language)

function DeleteLine(lines, line_number)

    
    
       local deletedLine = lines[line_number]
    
       -- do the actual deletion - move elements up
    
       return function() InsertLine(lines, line_number, deletedLine) end
    
     end
    
    
    
     function InsertLine(lines, line_number, deletedLine)
    
       -- do the actual insertion
    
       return function() DeleteLine(lines, line_number) end
    
     end
    
    
    

Again, not very efficient - but easy to grasp. Without closures would be hard
to compose - you would have to take care of a lot of extra parameters where
they need to be stored, etc.

~~~
schrototo
That's pretty neat, but returning the undo operation puts the responsibility
of actually keeping track of undo operations on the caller side. I think it'd
be better having each function push it's corresponding undo operation onto
some global undo stack, thereby ensuring every operation gets recorded,
without the caller having to do any work (or even know about the undo
functionality).

But of course, you don't really need closures for that. For example, Cocoa
does it this way:

    
    
       - (void)deleteLineAtRow:(NSUInteger)row {
         NSString *deletedLine = [self lineAtRow:row];
         [[self.undoManager prepareWithInvocationTarget:self] insertLine:deletedLine atRow:row];
         // do actual deletion
       }
    
       - (void)insertLine:(NSString *)line atRow:(NSUInteger)row {
         [[self.undoManager prepareWithInvocationTarget:self] deleteLineAtRow:row];
         // do actual insertion
       }
    

That -prepareWithInvocation: stuff tells the undoManager to store the next
message sent to it, along with it's parameters, on an internal stack. This is
of course depends on Objective-C's dynamic nature and there's a whole lot of
complexity hidden inside the undo manager object.

But mixing this undo manager concept with closures should be pretty
straightforward, resulting in something like this (note that this is a
hypothetical example; Cocoa does not currently implement this functionality):

    
    
       - (void)deleteLineAtRow:(NSUInteger)row {
         NSString *deletedLine = [self lineAtRow:row];
         [self.undoManager registerUndoWithBlock:^{
           [self insertLine:deletedLine atRow:row];
         }];
         // do actual deletion
       }
    
       - (void)insertLine:(NSString *)line atRow:(NSUInteger)row {
         [self.undoManager registerUndoWithBlock:^{
           [self deleteLineAtRow:row];
         }];
         // do actual insertion
       }

~~~
malkia
Thanks for that! I was mainly thinking that by returning functions, one can
compose for more complex editor operations, more functions at once, and even
simplify them (if they cancel each other). Off course this is not currently
possible, unless the returned functions are some kind of AST tree, and there
is something that can optimize them at runtime (dynamic programming?)...
Probably overkill....

For example deleteBlock might delete 10 lines, and if there is better
composability, instead of returning undo to insert 10 individual lines, it can
be merged as one operation with 10 lines, basically by having rules, if you
have production like "insertLine * insertLine * insertLine * insertLine" - you
can make this as "insertLines[lines collected]" - but that's beyond the
discussion.

All this just to avoid making insertBlock/deleteBlock special, but reuse
insertLine/deleteLine.... lost my thought already - too late in the
morning....

------
ttyS0
To save you time, you can skip the initial rant about how closures are not
taught in universities and start reading from the heading "A Concept Explained
Simply".

------
dmbass
This explanation did not add anything to help me better understand closures
and anonymous functions. I already understand that closures allow you to pass
an anonymous function around and it maintains the variables that were in its
scope when it was created (whether by copy or reference).

The problem, at least for me, is finding a non-trivial example of using an
anonymous function. Does anybody have other examples like malkia's[1] that
demonstrate why anonymous functions and closures are useful? Or maybe just a
good explanation of functional programming?

1\. <http://news.ycombinator.com/item?id=2919149>

~~~
spacemanaki
I think the classic example of using anonymous functions is probably as
arguments to map, filter, reduce, etc:

    
    
      > (mapcar #'(lambda (x) (+ x x)) (list 1 2 3 4))
      (2 4 6 8)
    

In that case, the anonymous function doesn't close over anything. Here's an
example where it does (from On Lisp):

    
    
      > (defun list+ (lst n)
          (mapcar #'(lambda (x) (+ x n))
                  lst))
      > (list+ (list 1 2 3) 10)
      (11 12 13)
    

In this case `n` is closed over.

Both of these ARE pretty trivial, but the point I'm trying to make is that
anonymous functions in many cases just make some code a bit more concise and
avoids the need for nested named functions, which I guess is common in Python
where `lambda` can only contain an expression.

I'm reading On Lisp now, and there are some examples early on of functions
that return functions. In those cases, the functions being returned are almost
always anonymous, just because naming them would be kind of verbose and
unnecessary.

There are other, more complicated uses, for instance closures can be used as a
sort of crude way of making objects, and supporting hacky encapsulation, which
is described in a lot of Scheme textbooks, like SICP:
[http://mitpress.mit.edu/sicp/full-text/book/book-
Z-H-21.html...](http://mitpress.mit.edu/sicp/full-text/book/book-
Z-H-21.html#%_sec_3.2.3)

As for functional programming, it's a lot more than just first-class,
anonymous and higher order functions. It also encourages or enforces pure
functions: functions in the mathematical sense that do not have side effects,
and always return the same value given the same arguments.

SICP is a good start, if you're curious about Lisp. It's a great book. There's
other places too though, to get this stuff, if you wanted to dive into the
Haskell world via Learn you a Haskell I'm sure you'd see some of what FP is
about. I'm less familiar with it though.

edited for clarity and fix the SICP link

------
rgrove
Back to the Future II is the best explanation of closures I've ever seen.

~~~
colanderman
I consider myself well-versed on both closures and BttF II but I don't
understand this comment. Care to explain?

~~~
rgrove
I'm referring to the scene in which Doc draws a diagram on a blackboard to
explain to Marty why the two of them still exist even though they've screwed
up history and created an alternate 1985. Essentially, they exist because
they're in a time closure and they carry their own pasts with them into
1985-B.

It's not a perfect analogy, but it's close enough that I've been able to use
that scene to help make closures click for someone who was having trouble
understanding them.

------
lispm
Closures are functions plus their bindings for its free variables. The
references to the bindings have lexical scope and indefinite extent.

------
jrvarela56
I dont understand the difference between a closure and an object's state. Is
an object one example of a closure? You can pass it around and it contains
instance variables.

What are lambdas for in this context? Simply calling the object's attribute
would return the value set at creation - even if modified afterwards.

~~~
jrvarela56
Hope this helps: (Python)

def closure(x): return lambda y:x+y

a = closure(5) #'a' is a function now a(2) #returns 7 a(3) #returns 8

The function 'closure' can be carried around and it remembers the value of x
from when it was created.

Got the example from this article: <http://linuxgazette.net/109/pramode.html>
(I believe it was shared a few weeks ago) - great reference for other FP
concepts and a good way to get started in FP if you already like working with
Python.

------
jabo
Wow, I've seen functions like these in Erlang, but I didn't realize their
usefulness until reading this.

