Tom Wyant

That's actually an interestging question - if you did this in a closure, does the subroutine if there are no longer any references to it get GC'd or do they remain somewhere in memory? You seem to be suggesting they do. I don't know the answer, but would like to. :-)

Having to retain the value at the time the closure was created is not a requirement I have ever seen in any definition of closures. (If that was required by the definition, then Perl would not have closures, period, because a variable name in Perl always binds to a reference, not a value.) In fact every example I can back to emphasises the fact that the value of a closed-over variable can be updated and will then be seen by all of the functions that have closed over that particular instance of the variable.

Pretty much every every single Google result shows the same definition: https://www.google.com/search?q=define+Closure+programming

You seemed to be saying that

sub make_adder {
    my ( $addend ) = @_;
    return sub { $_[0] + $addend };
}

is an example of one closure but

sub make_adder_and_setter {
    my ( $addend ) = @_;
    return (
        sub { $_[0] + $addend },
        sub { $addend = $_[0] },
    );
}

is an example with zero closures rather than (correctly) two closures, merely because the second closure mutates the variable. (If that is not what you were saying, I am not sure what “even if those values subsequently change” is supposed to have meant.)

Correct. If you do something like

my ( @getter, @setter );
for my $i ( 'a' .. 'z' ) {
    my $value = $i;
    push @getter, sub { $value };
    push @setter, sub { $value = $_[0] };
}

then the closures in $getter[0] and $setter[0] will refer to the same instance of $value.

I.e. if you do

$setter[0]->( $something );
say $getter[0]->();

you will get the $something printed that you just set.

But while $getter[0] and $setter[0] refer to the same instance of $value, it’s a different instance than the one $getter[1] and $setter[1] (or any other pair) both refer to.

Because of the my declaration, a new instance of $value is created on every iteration of the loop, therefore subs created during different iterations of the loop refer to different instances of the variable. But for the same reason, all subs created during the same iteration of the loop refer to the same instance.

And the fact that the variable is declared outside those subs but they retain a reference to a particular instance of it is indeed what makes those subs closures. The value of the variable may well change, it’s the retention of a particular instance that counts.

Ah, I didn’t properly register that you were talking about named subs. Yes, named subs aren’t special in any way in this regard. The only thing that distinguishes them from unnamed subs is that they get assigned to a glob slot in the package stash, which isn’t relevant in closure terms. They also get created very early on in the execution of the program, which is much more relevant – though not a defining feature. Named subs will in fact be closures if they refer to my variables declared e.g. at the top scope of the file as (faux!) globals.

This is, btw – since we’re in a series on warnings! – what the “Variable "…" will not stay shared” warning is all about. If you define a named sub inside another sub, well – named subs are created just once, immediately when they are parsed, and if the (seemingly) inner, named sub closes over a variable declared in the outer sub, then it will retain a reference to the instance of the variable from during compilation, whereas each call of the outer sub will create new instances of these variables. So something like this cannot work:

sub complicated_sub {
  # ...
  my $var;
  sub some_util_func { $var = some_long_expression @_ }
  # ...
  some_util_func( $something );
  # oops, the $var we can access here has not changed!
  # ...
}

because some_util_func closes over $var, and since named subs are created only once, it retains the initial instance of $var created while complicated_sub was being compiled – whereas the my in complicated_sub creates an entirely new instance of $var for every call of complicated_sub, and that instance is always(!) different from the instance that some_util_func has closed over.

I am willing to write it up, no problem. The problem I do have is I don’t know quite what the opening of such an article would look like. Here in this comment section, the choice of facts to outline was motivated by your statements. I’m not sure how to divorce the explanation from that context; setting it up by conveying your previous understanding of closures in order to launch into its correction doesn’t seem a deft way to bring the reader along. I need some hook for the explanation.