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

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.

Are you saying that everyone who creates a class has to build a potentially exhaustive set of classes and subclasses so that no one can see things that don't belong to them?

The block rovf showed, and which you label a 'closure' doesn't reference a variable outside of its scope.

The scope in which the variable exists ceases to exist long before the function was called. The function definitely references an out-of-scope variable.

[ And JavaFan didn't say otherwise. Oops! ]

$ perl -MO=Concise,foo,-exec -e'{ my $x; sub foo { $x } }'
main::foo:
1  <;> nextstate(main 2 -e:1) v
2  <0> padsv[$x:FAKE:]               <-- Is "FAKE": closed over
3  <1> leavesub[1 ref] K/REFC,1
-e syntax OK
[download]

You seem to think nesting a named sub is the same as nesting blocks, but that's not the case at all. The scope of the outer block still exists when the the inner block is being executed.

$ perl -MO=Concise,-exec -e'{ my $x; { $x } }'
1  <0> enter
2  <;> nextstate(main 4 -e:1) v:{
3  <{> enterloop(next->b last->b redo->4) v
4  <;> nextstate(main 1 -e:1) v
5  <0> padsv[$x:1,3] vM/LVINTRO
6  <;> nextstate(main 3 -e:1) v
7  <{> enterloop(next->a last->a redo->8) v
8  <;> nextstate(main 2 -e:1) v
9  <0> padsv[$x:1,3] v               <-- Not "FAKE": in scope
a  <2> leaveloop vK/2
b  <2> leaveloop vK/2
c  <@> leave[1 ref] vKP/REFC
-e syntax OK
[download]

The scope in which the variable exists ceases to exist long before the function was called. The function definitely references an out-of-scope variable.

Yes. What's your point here? I don't think I claimed the function doesn't.

Let me requote doug:

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

And the block discussed here is the following posted by rovf:

{ # closure starts here
  my $shared_variable;
  sub ref_test1 { ... }
  sub ref_test2 { ... }
}
[download]

Or are you going to retract your retraction about the outer block being a closure?

You seem to think nesting a named sub is the same as nesting blocks

Where did you get that idea from? Why does that even matter in my argument with doug that a closure is something else than just a block giving scope to a variable?

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.