They are closures. But Ruby can do interesting and slightly reckless things, like transplanting a closure into a different evaluation scope. It’s very powerful, and also very dangerous in the wrong hands.
It's a closure. The lisp equivalent is also a closure, and the JS equivalent is a function (which is a closure as they can refer to variables in the scope they're defined in. To test this define a function inside a function and reference variables defined in the outer function, and return the inner function).
I mean, that is the point of a closure. The name refers to closing over its environment.
In terms of implementation, the closure needs to keep a reference to its environment, so it may be "transplanted" but it effectively runs in its own scope.
That's what I'm saying: In Ruby, you can transplant code from a closure out of its lexical scope and evaluate it as if it was defined in a different environment.
My point is that this isn't "reckless" - it's a core part of the value of a closure.
We do this regularly enough in Ruby - usually with lambda rather than proc/blocks because of the return semantics, but you can do it just as safely with proc/blocks as long as you don't call "return" within them (there's no reason to, on the other hand).
It's a way of e.g. building generator methods that returns distinct callable objects without constructing a whole class. In that case the closure environment effectively becomes the instance variables.
