I wrote:

Any block that creates scoped variables is a closure in my book.

And you replied:

So, only blocks that don't create scoped variables aren't not closures? That's not a very useful definition. It's also a definition that's quite different from what other people use. Using your own definitions doesn't promote communication
Note that the important thing of what the rest of Perl world calls closures is the reference to lexical variables defined outside of the scope. The block rovf showed, and which you label a 'closure' doesn't reference a variable outside of its scope.

I must be missing something here. I don't remember replying to rofv. The thing I called a closure was introduced by me. It features two subroutines that, when called, access the variable $type, which has gone out of scope. Due to the closure formed by the anonymous block, $type remains, although it is only accessible via those two subroutines.

Go re-read perlfaq7: It gives an example of using the BEGIN block do make a private variable just like I described. The section describing this in perlsub is called Persistent variables with closures.

In perl there isn't really much of a difference between a subroutine and a block, so my use of closure includes either one. Any block is a potential closure in that it can potentially provide scope for a variable that will persist in a subroutine after the end of the block.

I don't see why named blocks (subroutines) are given special status when the mechanism is more general than that. If the mechanism I showed is not a true closure, what would you call it? And how would you differentiate it from a closure via a subroutine?

Googling for the term in various tutorials, I see your point that the first example is nearly always centered around subroutines, often with names like inner() and outer(). I think that is to make the examples easier to understand more than any particular desire to limit the term to subroutines.

- doug

PS: Yeah, I did screw up that definition. I left off the requirement that there has to be a way to get to those variables after the end of the scope of that block. Oops. Data without accessors just doesn't cut it. If that is the origin of this dispute, then I apologize for being unclear.