In programming languages, a closure is an abstraction of an expression in an environment; the expression may contain free variables which are given meaning by the values bound to them in the environment.

That's how I use the term, anyway. The general idea is that the closure "closes over" some data, capturing it. Note, though, that this use of the word "closure" has barely any relationship to the mathematical notion of closure (which basically means to keep doing something over and over until there is nothing more that will change.)

There are a few other concepts that are generally conflated with the idea of a closure. One is the function: you can call it, it performs some computations, perhaps updates some data or accesses some other processes or devices as a side-effect, and perhaps returns some value. The other is the so-called first-class value: they can be stored in variables, passed as arguments to a function, and returned as the return value of a function.

In practice, closures are almost always both of those things too. But it's an arrangement of convenience rather than necessity; nothing in (my) definition of a closure strictly requires those two properties.

You can have closures which are not first-class; maybe you can only return them from a function, but you can't pass them around. I don't know why you'd want to have this restriction, but you could, and it wouldn't stop them from being closures.

You can have closures which are not functions; for example, you could have a class or a module or some other construct close over some values, too. In a weak sense, any object whose data is initialized via arguments to its constructor, is a closure. It's perhaps not very useful to think of it that way, but it is also hard to make a coherent argument that it is not a closure.

And of course, you can have a first-class function value which is still not a closure because it doesn't close over anything. C's function pointers fit this bill.

I think one of the main reasons the conceptual ties between closures and first-class functions are so close is that, in the lambda calculus, the granddaddy of all functional languages, every function is a closure.

Closures seem to be one of those things that are a bit troubling to many programming languages, though.

LISP was the first language to promote functions as values, but it represented functions as lists and used dynamic binding to associate values with variables. This was a mess, and it took a long time for it to get better. Nowadays, Scheme has proper closures, and is a much more attractive choice overall (to me).

Python 2's closures are limited to a single expression. This may be a syntactic problem rather than a semantic one, but it is still something of an annoyance.

And then there's Ruby, which... yeah, I'm pretty sure that among Ruby's 4 types of procedure, there are closures somewhere.

Javascript has had closures from its beginnings — the problems there have been teaching them to web developers, who might not be experienced programmers who can appreciate their subtleties, and implementing them. In the past they've been notorious for leaking. Partly this is a consequence of the difficulty of interpreting the definitions of the DOM — what should and what shouldn't stick around for how long.

And that brings up the topic of memory management. Since the environment of a closure may contain variables local to the function in which it is created, and since the closure may be returned as a value from that function, it may outlive the local variables referred to by its environment. For this reason, the language (and by extension its implementations) must ensure that those values continue to exist for as long as the closure itself exists, for example by allocating them on the heap instead of on the call stack.

By overloading the () operator, it's possible to make closure-like objects even in C++. (pikhq has also demonstrated that with fancy enough tricks you can also do this in C.) But if you try this, you'll soon appreciate why, in most languages, closures are garbage collected: if you have to explicitly reason about when the free variables will no longer be needed, you're not much better off from using function pointers.

Many modern languages that didn't initially support closures are growing support for them because they're becoming more popular. You've always been able to make a closure in Java by instantiating an anonymous class with a single method on it and initializing the member variables of that class with the values you want that method to close over, but doing so is as awkward as this sentence, so more direct support for the idea has been proposed in later versions. PHP is also gaining support for anonymous functions.

In contrast, Perl has had straight-up, no-nonsense closures from the beginnings of version 5, a pretty nice point in its favour.