[JonChesterfield]

The idea is to move variables from the body of the function to the argument list and rewrite the call sites to match.

That decreases the size of the closure (and increases the size of the code, and of however you're passing arguments).

Do it repeatedly though and you end up with no free variables, i.e. no closure to allocate. Hence the name, the lambda (closure) has been lifted (through the call tree) to the top level, where it is now a function (and not a lambda, if following the usual conflating of anonymous function with allocated closure).

Doesn't work in the general case because you can't find all the call sites.

[zozbot234]

I think the "no closure to allocate" is not quite right because the captured parameters of a first-class function still need to be stored somewhere. It just happens as part of the calling code, e.g. consider how a "function object" in C++/Java works: the operator() or .call() code does not need to allocate anything, but the allocation might occur as part of constructing the object itself.

[mrkeen]

Once they've been converted from free variables to formal parameters then it's assumed you can just stack allocate them, and roll them off when you return from your lambda (which is no longer a closure)