I do not think it is useful to interpret it as 0 or more. To me it only make sense to assume 1 or more. Otherwise you could say that the programming language that do not support closing variables, has nonetheless closures, as according to that notion every function is a closure that closes nothing.

The key difference here is whether the language allows closure over the lexical environment, not whether the lexical environment contains anything used.

You can see this in Ruby where methods don't close over the environment, but blocks do, clearly Ruby methods aren't closures, not even when reïfied into a Method, whereas blocks are closures.

I think this is a rectangle/square problem. When you say you accept/return a closure, you probably mean a "function + lexical scope of 0 or more variables". You can still refer to "non-closures" as functions, though.

It's like code expecting rectangles wouldn't mind to get squares, but a code expecting squares will definitely do mind getting rectangles.

>It's like code expecting rectangles wouldn't mind to get squares, but a code expecting squares will definitely do mind getting rectangles.

It is actually not that obvious since in OOP neither a square or a rectangle type is properly a subtype of the other. [0]

I understand how implementation-wise it could be convenient to treat a function as a closure. Although, I would prefer some other type, eg:

    functoid := closure | function

[0] - https://stackoverflow.com/questions/1030521/is-deriving-squa...

Well no, because a closure is a function and an environment. A function closing over nothing is different than a function being unable to close over something.

You might define the interface of a closure as `closure(f: Function, env: Mapping[str, Any])`, or in other words a closure is a function and a mapping of variable names to values. That mapping can be empty, but that's different than the different interface `not_a_closure(f: Function)`, which is incapable of closing over anything, including the empty set.