2 ms·

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 th

by kukx 9y ago

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.

TeMPOraL 9y ago
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.
- kukx 9y ago
  >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-square-from-rectangle-a-violation-of-liskovs-substitution-principle https://stackoverflow.com/questions/1030521/is-deriving-squa...
irishsultan 9y ago
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.
joshuamorton 9y ago
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.

by kukx 9y ago

TeMPOraL 9y ago

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.

kukx 9y ago
>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-square-from-rectangle-a-violation-of-liskovs-substitution-principle https://stackoverflow.com/questions/1030521/is-deriving-squa...

irishsultan 9y ago

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.

joshuamorton 9y ago

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.