Why would a program use a closure?

Question

After reading many posts explaining closures here I'm still missing a key concept: Why write a closure? What specific task would a programmer be performing that might be best served by a closure?

Examples of closures in Swift are accesses of an NSUrl and using the reverse geocoder. Here is one such example. Unfortunately, those courses just present the closure; they do not explain why the code solution is written as a closure.

An example of a real world programming problem that might trigger my brain to say, "aha, I should write a closure for this", would be more informative than a theoretical discussion. There is no shortage of theoretical discussions available on this site.

Answer 1

First of all, there is nothing that is impossible without using closures. You can always replace a closure by an object implementing a specific interface. It's only a matter of brevity and reduced coupling.

Second, keep in mind that closures are often used inappropriately, where a simple function reference or other construct would be more clear. You shouldn't take every example you see as a best practice.

Where closures really shine over other constructs is when using higher-order functions, when you actually need to communicate state, and you can make it a one-liner, as in this JavaScript example from the wikipedia page on 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; }
    );
}

Here, threshold is very succinctly and naturally communicated from where it is defined to where it is used. Its scope is precisely limited as small as possible. filter doesn't have to be written to allow for the possibility of passing client-defined data like a threshold. We don't have to define any intermediate structures for the sole purpose of communicating the threshold in this one small function. It's entirely self-contained.

You can write this without a closure, but it will require a lot more code, and be harder to follow. Also, JavaScript has a fairly verbose lambda syntax. In Scala, for example, the entire function body would be:

bookList filter (_.sales >= threshold)

If you can however use ECMAScript 6, thanks to the fat arrow functions even the JavaScript code becomes much simpler and can be actually put on a single line.

const bestSellingBooks = (threshold) => bookList.filter(book => book.sales >= threshold);

In your own code, look for places where you generate a lot of boilerplate just to communicate temporary values from one place to another. These are excellent opportunities to consider replacing with a closure.

Answer 2

By way of explanation, I'm going to borrow some code from this excellent blog post about closures. It's JavaScript, but that's the language most blog posts that talk about closures use, because closures are so important in JavaScript.

Let's say you wanted to render an array as an HTML table. You could do it like this:

function renderArrayAsHtmlTable (array) {
  var table = "<table>";
  for (var idx in array) {
    var object = array[idx];
    table += "<tr><td>" + object + "</td></tr>";
  }
  table += "</table>";
  return table;
}

But you're at the mercy of JavaScript as to how each element in the array will be rendered. If you wanted to control the rendering, you could do this:

function renderArrayAsHtmlTable (array, renderer) {
  var table = "<table>";
  for (var idx in array) {
    var object = array[idx];
    table += "<tr><td>" + renderer(object) + "</td></tr>";
  }
  table += "</table>";
  return table;
}

And now you can just pass a function that returns the rendering you want.

What if you wanted to display a running total in each Table Row? You would need a variable to track that total, wouldn't you? A closure allows you to write a renderer function that closes over the running total variable, and allows you to write a renderer that can keep track of the running total:

function intTableWithTotals (intArray) {
  var total = 0;
  var renderInt = function (i) {
    total += i;
    return "Int: " + i + ", running total: " + total;
  };
  return renderObjectsInTable(intArray, renderInt);
}

The magic that is happening here is that renderInt retains access to the total variable, even though renderInt is repeatedly called and exits.

In a more traditionally object-oriented language than JavaScript, you could write a class that contains this total variable, and pass that around instead of creating a closure. But a closure is a much more powerful, clean and elegant way of doing it.

Further Reading

• MDN on Closures
• How do JavaScript closures work?

Answer 3

The purpose of closures is simply to preserve state; hence the name closure - it closes over state. For the ease of further explanation, I'll use Javascript.

Typically you have a function

function sayHello(){
    var txt="Hello";
    return txt;
}

where the scope of the variable(s) is bound to this function. So after execution the variable txt goes out of scope. There is no way of accessing or using it after the function has finished execution.

Closures are language construct, which allow - as said earlier - to preserve the state of the variables and so prolong the scope.

This could be useful in different cases. One use case is the construction of higher order functions.

In mathematics and computer science, a higher-order function (also functional form, functional or functor) is a function that does at least one of the following:1

• takes one or more functions as an input
• outputs a function

A simple, but admittely not all too useful example is:

 makeadder=function(a){
     return function(b){
         return a+b;
     }
 }

 add5=makeadder(5);
 console.log(add5(10)); 

You define a function makedadder, which takes one parameter as input and returns a function. There is an outer function function(a){} and an inner function(b){}{}.Further you define (implicitely) another function add5 as the result of calling the higher order funtion makeadder. makeadder(5) returns an anonymous (inner) function, which in turn takes 1 parameter and returns the sum of the parameter of the outer function and the parameter of the inner function.

The trick is, that while returning the inner function, which does the actual adding, the scope of the parameter of the outer function (a) is preserved. add5 remembers, that the parameter a was 5.

Or to show one at least somehow usefull example:

  makeTag=function(openTag, closeTag){
     return function(content){
         return openTag +content +closeTag;
     }
 }

 table=makeTag("<table>","</table>")
 tr=makeTag("<tr>", "</tr>");
 td=makeTag("<td>","</td>");
 console.log(table(tr(td("I am a Row"))));

Another common usecase is the so called IIFE = immediately invoked function expression. It is very common in javascript to fake private member variables. This is done via a function, which creates a private scope = closure, because it is immediatly after definition invoked. The structure is function(){}(). Notice the brackets () after the definition. This makes it possible to use it for object-creation with revealing module pattern. The trick is creating a scope and returning an object, which has access to this scope after execution of the IIFE.

Addi's example looks like this:

 var myRevealingModule = (function () {

         var privateVar = "Ben Cherry",
             publicVar = "Hey there!";

         function privateFunction() {
             console.log( "Name:" + privateVar );
         }

         function publicSetName( strName ) {
             privateVar = strName;
         }

         function publicGetName() {
             privateFunction();
         }


         // Reveal public pointers to
         // private functions and properties

         return {
             setName: publicSetName,
             greeting: publicVar,
             getName: publicGetName
         };

     })();

 myRevealingModule.setName( "Paul Kinlan" );

The returned object has references to functions (e.g. publicSetName), which in turn have access to "private" variables privateVar.

But these are more special use cases for Javascript.

What specific task would a programmer be performing that might be best served by a closure?

There are several reasons for that. One might be, that it is natural for him, since he follows a functional paradigm. Or in Javascript: it is mere necessity to rely on closures to circumvent some quirks of the language.

Answer 4

There are two main use cases for closures:

1. Asynchrony. Let's say you want to perform a task that will take a while, and then do something when it's done. You can either make your code wait for it to be done, which blocks further execution and can make your program unresponsive, or call your task asynchronously and say "begin this long task in the background, and when it completes, execute this closure", where the closure contains the code to execute when it's done.

2. Callbacks. These are also known as "delegates" or "event handlers" depending on the language and platform. The idea is that you have a customizable object that, at certain well-defined points, will execute an event, which runs a closure passed in by the code that sets it up. For example, in your program's UI you might have a button, and you give it a closure that holds the code to be executed when the user clicks on the button.

There are several other uses for closures, but those are the two main ones.

Answer 5

A couple of other examples:

Sorting
Most sort functions operate by comparing pairs of objects. Some comparison technique is needed. Restricting the comparison to a specific operator means a rather inflexible sort. A much better approach is to receive a comparison function as an argument to the sort function. Sometimes a stateless comparison function works fine (e.g., sorting a list of numbers or names), but what if the comparison needs state?

For example, consider sorting a list of cities by distance to some specific location. An ugly solution is to store the coordinates of that location in a global variable. This makes the comparison function itself stateless, but at the cost of a global variable.

This approach precludes having multiple threads simultaneously sorting the same list of cities by their distance to two different locations. A closure that encloses the location solves this problem, and it gets rid of the need for a global variable.

Random numbers
The original rand() took no arguments. Pseudorandom number generators need state. Some (e.g., Mersenne Twister) need lots of state. Even the simple but terrible rand() needed state. Read a math journal paper on a new random number generator and you'll inevitably see global variables. That's nice for the developers of the technique, not so nice for the callers. Encapsulating that state in a structure and passing the structure to the random number generator is one way around the global data problem. This is the approach used in many non-OO languages to making a random number generator reentrant. A closure hides that state from the caller. A closure offers the simple calling sequence of rand() and the reentrancy of encapsulated state.

There's more to random numbers than just a PRNG. Most people who want randomness want it distributed a certain way. I'll start with numbers randomly drawn from between 0 and 1, or U(0,1) for short. Any PRNG that generates integers between 0 and some maximum will do; simply divide (as a floating point) the random integer by the maximum. A convenient and generic way to implement this is to create a closure that takes a closure (the PRNG) and the maximum as inputs. Now we have a generic and easy to use random generator for U(0,1).

There are a number of other distributions besides U(0,1). For example, a normal distribution with a certain mean and standard deviation. Every normal distribution generator algorithm I've run across uses a U(0,1) generator. A convenient and generic way to create a normal generator is to create a closure that encapsulates the U(0,1) generator, the mean, and the standard deviation as state. This is, at least conceptually, a closure that takes a closure that takes a closure as an argument.

Answer 6

Closures are equivalent to objects implementing a run() method, and inversely, objects can be emulated with closures.

• The advantage of closures is that they can be used easily anywhere you expect a function: a.k.a. higher-order functions, simple callbacks (or Strategy Pattern). You don't need to define an interface/class to build ad-hoc closures.

• The advantage of objects is the possibility to have more complex interactions: multiple methods and/or different interfaces.

So, using closure or objects is mostly a matter of style. Here is an example of things that closures make easy but is inconvenient to implement with objects:

 (let ((seen))
    (defun register-name (name)
       (pushnew name seen :test #'string=))

    (defun all-names ()
       (copy-seq seen))

    (defun reset-name-registry ()
       (setf seen nil)))

Basically, you encapsulate a hidden state that is accessed only through global closures: you don't need to refer to any object, only use the protocol defined by the three functions.

---

• I am extending the answer to address this comment from supercat*.

I trust supercat's first comment on the fact that in some languages, it is possible to control precisely the lifetime of objects, whereas the same thing is not true for closures. In the case of garbage-collected languages, however, the lifetime of objects are generally unbounded, and it is thus possible to build a closure that could be called in a dynamic context where it should not be called (reading from a closure after a stream is closed, for example).

However, it is quite simple to prevent such misuse by capturing a control variable that will guard the execution of a closure. More precisely, here is what I have in mind (in Common Lisp):

(defun guarded (function)
  (let ((active t))
    (values (lambda (&rest args)
              (when active
                (apply function args)))
            (lambda ()
              (setf active nil)))))

Here, we take a function designator function and return two closures, both of them capturing a local variable named active:

• the first one delegates to function, only when active is true
• the second one sets action to nil, a.k.a. false.

Instead of (when active ...), it is of course possible to have an (assert active) expression, which could throw an exception in case the closure is called when it should not be. Also, keep in mind that the unsafe code might already throw an exception by itself when used badly, so you rarely need such a wrapper.

Here is how you would use it:

(use-package :metabang-bind) ;; for bind

(defun example (obj1 obj2)
  (bind (((:values f f-deactivator)(guarded (lambda () (do-stuff obj1))))
         ((:values g g-deactivator)(guarded (lambda () (do-thing obj2)))))

    ;; ensure the closure are inactive when we exit
    (unwind-protect
         ;; pass closures to other functions
         (progn
           (do-work f)
           (do-work g))

      ;; cleanup code: deactivate closures
      (funcall f-deactivator)
      (funcall g-deactivator))))

Note that the desactivating closures could also be given to other functions as well; here, the local active variables are not shared between f and g; also, in addition to active, f only refers to obj1 and g only refers to obj2.

The other point mentioned by supercat is that closures can lead to memory leaks, but unfortunately, it is the case for almost everything in garbage-collected environments. If they are available, this can be solved by weak pointers (the closure itself might be kept in memory, but does not prevent garbage-collection of other resources).

Answer 7

Nothing that hasn't been said already, but maybe a simpler example.

Here's a JavaScript example using timeouts:

// Example function that logs something to the browser's console after a given delay
function delayedLog(message, delay) {
  // this function will be called when the timer runs out
  var fire = function () {
    console.log(message); // closure magic!
  };

  // set a timeout that'll call fire() after a delay
  setTimeout(fire, delay);
}

What happens here, is that when delayedLog() is called, it returns immediately after setting the timeout, and the timeout keeps ticking down in the background.

But when the timeout runs out and calls the fire() function, the console will display the message that was originally passed to delayedLog(), because it is still available to fire() via closure. You can call delayedLog() as much as you want, with a different message and delay each time, and it'll do the right thing.

But let's imagine JavaScript doesn't have closures.

One way would be to make setTimeout() blocking - more like a "sleep" function - so delayedLog()'s scope does not go away until the timeout has run out. But blocking everything isn't very nice.

Another way would be to put the message variable in some other scope that'll be accessible after delayedLog()'s scope is gone.

You could use global - or at least "broader scoped" - variables, but you'd have to figure out how to keep track of what message goes with what timeout. But it can't just be a sequential, FIFO queue, because you can set any delay you want. So it might be "first in, third out" or something. So you'd need some other means to tying a timed function to variables it needs.

You could instantiate a timeout object that "groups" the timer with the message. An object's context is more or less a scope that sticks around. Then you'd have the timer execute in the object's context, so it'd have access to the right message. But you'd have to store that object because without any references it'd get garbage collected (without closures, there'd be no implicit references to it either). And you'd have to remove the object once it's fired its timeout, otherwise it'll just stick around. So you'd need some sort of list of timeout objects, and periodically check it for "spent" objects to remove - or the objects would add and remove themselves from the list, and...

So... yeah, this is getting dull.

Thankfully, you don't have to use a broader scope, or wrangle objects just to keep certain variables around. Because JavaScript has closures, you already have exactly the scope your need. A scope that gives you access to the message variable when you need it. And because of that, you can get away with writing delayedLog() like above.

Answer 8

PHP can be used to help to show a real example in a different language.

protected function registerRoutes($dic)
{
  $router = $dic['router'];

  $router->map(['GET','OPTIONS'],'/api/users',function($request,$response) use ($dic)
  {
    $controller = $dic['user_api_controller'];
    return $controller->findAllAction($request,$response);
  })->setName('api_users');
}

So basically I am registering a function which will be executed for the /api/users URI. This is actually a middleware function which ends up being stored on a stack. Other functions will be wrapped around it. Pretty much like Node.js/Express.js does.

The dependency injection container is available (via the use clause) inside the function when it gets called. It's possible to make some sort of route action class, but this code turns out to be simpler, faster and easier to maintain.

Answer 9

A closure is a piece of arbitrary code, including variables, that can be handled as first class data.

A trivial example is good old qsort: It's a function to sort data. You have to give it a pointer to a function that compares two objects. So you have to write a function. That function might need to be parameterized, which means you give it static variables. Which means it isn't thread safe. You are in DS. So you write an alternative that takes a closure instead of a function pointer. You instantly solve the problem of parameterization because the parameters become part of the closure. You make your code more readable because you write how objects are compared directly with the code that calls the sorting function.

There are tons of situations where you want to perform some action that requires a good deal of boiler plate code, plus one tiny but essential piece of code that needs to be adapted. You avoid the boilerplate code by writing a function once that takes a closure parameter and does all the boilerplate code around it, and then you can call this function and pass the code to be adapted as a closure. A very compact and readable way to write code.

You have a function where some non-trivial code needs to be performed in many different situation. This used to produce either code duplication or contorted code so that the non-trivial code would be present only once. Trivial: You assign a closure to a variable and call it in the most obvious way wherever it is needed.

Multithreading: iOS / MacOS X has functions to do things like "perform this closure on a background thread", "... on the main thread", "... on the main thread, 10 seconds from now". It makes multithreading trivial.

Asynchronous calls: That's what the OP saw. Any call that accesses the internet, or anything else that could take time (like reading GPS coordinates) is something where you can't wait for the result. So you have functions that do things in the background, and then you pass a closure to tell them what to do when they are finished.

That's a small start. Five situations where closures are revolutionary in terms of producing compact, readable, reliant, and efficient code.

Answer 10

A closure is a shorthand way of writing a method where it is to be used. It saves you the effort of declaring and writing a separate method. It is useful when the method will be used only once and the method definition is short. The benefits are reduced typing as there is no need to specify the name of the function, its return type or its access modifier. Also, when reading the code you don't have to look elsewhere for the method's definition.

The above is a summary of Understand Lambda Expressions by Dan Avidar.

This clarified the use of closures for me because it clarifies the alternatives (closure vs. method) and the benefits of each.

The following code is used once, and once only during setup. Writing it in place under viewDidLoad saves the trouble of searching for it elsewhere, and shortens the size of the code.

myPhoton!.getVariable("Temp", completion: { (result:AnyObject!, error:NSError!) -> Void in
  if let e = error {
    self.getTempLabel.text = "Failed reading temp"
  } else {
    if let res = result as? Float {
    self.getTempLabel.text = "Temperature is \(res) degrees"
    }
  }
})

In addition, it provides for an asynchronous process to complete without blocking other parts of the program, and, a closure will retain a value for reuse in subsequent function calls.

Another closure; this one captures a value...

let animals = ["fish", "cat", "chicken", "dog"]
let sortedStrings = animals.sorted({ (one: String, two: String) -> Bool in return one > two
}) println(sortedStrings)