funarg problems
Found a good, old, post on a Scheme mailing list which explains the historical context behind the very confusing terms “closure”, “downwards funargs problem”, and “upwards funargs problem”: Max Hailperin in 2001.
The reason is that [the term] “closure” only makes sense in a particular historical context, where procedures had previously been left “open”, that is with free variables not associated with any particular binding. This was the case in various pre-Scheme Lisps, and lead to what was known as the “funarg problem,” short for “functional argument”, though it also was manifested when procedures were used in other first-class ways than as arguments, for example, as return values, where it was confusingly called the “upward funarg problem” (by contrast to the “downward funarg problem,” where the arg was genuinely an arg). The “funarg problem” is what logicians had been calling “capture of free variables,” which occurs in the lambda calculus if you do plain substitution, without renaming, in place of proper beta-reduction.
So anyhow, an evolutionary milestone in the development of the Lisp family of languages was the realizations that procedures should be “closed”, that is, converted into a form where all the variables are bound rather than free. (The way this is normally done, as others have written in this thread, is by associating the procedure text, which still has free variables, with a binding environment that provides the bindings.)
Because this was such a big deal in terms of the languages’ evolution, Lisp hackers took to using the word “closure” rather than just “procedure” to emphasize that they were talking about this great new lexically scoped kind of procedure.
An awesome function
As seen in a random Reddit comment:
def yesterdays_date():
yesterday = time.localtime()
time.sleep(86400)
return yesterday