> Personally, I tend to think of closures as something you can make multiple instances of
That's a further concept, building on top of closures.
In what you show foo is a "generator" returning an anonymous sub, which is indeed enclosing $x ... but that's not necessary for a closure.
A "closure" is the combination of a sub and "enclosed"° vars from the outer scope.
you don't need generators for closures...
see also Closure (computer programming) :
"Operationally, a closure is a record storing a function together with an environment."
But it's true that many - including me - often simply say "closure" for the "closure function"
> but if the code you showed was in a block, then I guess that can fit the definition of a closure too
an explicit block is just cosmetics, since the file-scope acts as a default block.
> since the subs are then the only thing to hold references to the variables.
That's bit confusing ... a sub will only hold reference to a variable form a surrounding scope if it's enclosed, i.e. explicitly used. You don't need a block to enforce this.
Consider this example, where the second bar() will fail because there is no explicit use of $var, just a symbolic reference.
Since it's not bound - here realized as the scratch pads of the sub increasing the ref-count - it can be destroyed.
NB: I just need the block here because all calls are in the same file.
use v5.12;
use warnings;
use Data::Dump qw/pp dd/;
{
my $var = 42;
sub foo {
warn $var;
}
sub bar {
eval 'warn $var';
}
foo();
bar();
}
foo();
bar();
42 at c:/tmp/pm/closure_demo.pl line 9.
42 at (eval 1) line 1.
42 at c:/tmp/pm/closure_demo.pl line 9.
Variable "$var" is not available at (eval 2) line 1.
Use of uninitialized value $var in warn at (eval 2) line 1.
Warning: something's wrong at (eval 2) line 1.
updates
°) lexical vars in this case, package vars are just globally available... |