Groovy Concept of Closure

Question

I'm a bit confused as to the term "closure" used within the Groovy documentation. According to the documentation, their definition of a closure seems more like an anonymous function or lambda.

I understand that languages that support first class functions, typically allow closures to be formed. However, there is a distinction between the two concepts.

For example, according to the Groovy docs:

A closure in Groovy is an anonymous chunk of code that may take arguments, return a value, and reference and use variables declared in its surrounding scope.

In functional language parlance, such an anonymous code block might be referred to as an anonymous lambda expression in general or lambda expression with unbound variables or a closed lambda expression if it didn't contain references to unbound variables (like threshold in the earlier example). Groovy makes no such distinction.

Then according to the Wikipedia page on Closures:

The term closure is often mistakenly used to mean anonymous function.

What am I missing?

Answer 1

As it says in the next paragraph of the same page you linked to in the groovy docs:

Strictly speaking, a closure can't be defined. You can define a block of code that refers to local variables or fields/properties, but it becomes a closure only when you "bind" (give it a meaning) this block of code to variables. The closure is a semantic concept, like an instance, which you cannot define, just create. Strictly spoken a closure is only a closure if all free variables are bound. Unless this happens it is only partially closed, hence not really a closure. Since Groovy doesn't provide a way to define a closed lambda function and a block of code might not be a closed lambda function at all (because it has free variables), we refer to both as closure - even as syntactic concept. We are talking about it as syntactic concept, because the code of defining and creating an instance is one, there is no difference. We very well know that this terminology is more or less wrong, but it simplifies many things when talking about code in a language that doesn't "know" the difference.