anonymous vs named subroutines as closures

Clovis_Sangrail has asked for the wisdom of the Perl Monks concerning the following question:

It is troubling when you encounter what look like contradictions between divine(?) authority and observed behavior. I'm reading the original (2003) Alpaca book, learning of closures. Quoting page 73:

"A subroutine doesn't have to be an anonymous subroutine to be a closure. If a named subroutine accesses lexical variables and those variables go out of scope, the named subroutine retains a reference to the lexicals, just as you saw with anonymous subroutines."

OK, great, because I'd like to write the "ask_monkey_about" subroutine referred to in chapter 7 as a closure defined in a subroutine, and pass usage data into a lexical variable in that enclosing subroutine. (I want to try out this 'Schwartzian Transform' thingy.)

But I find that my "ask_monkey_about" named subroutine:

sub cookup2 {
    my %usd = @_;
    sub ask_monkey_about {
        my $cst = shift;
        $usd{$cst};
    };
}
[download]

generates the ominous-sounding warning:

Variable "%usd" will not stay shared at t15.pl line 11.

The warning goes away if I instead define an anonymous subroutine within the enclosing subroutine. I did both, and ran it, and both versions seem to work:

$ cat t15.pl

use strict;
use warnings;

my @usages = qw( Gilligan 23 Thurston 70 Lovey 98 );
my $ask;

sub cookup2 {
    my %usd = @_;                       # Better be even #.
    sub ask_monkey_about {
        my $cst = shift;
        $usd{$cst};
    };
}

sub cookup {
    my %usd = @_;                       # Better be even #.
    return sub {
        my $cst = shift;
        $usd{$cst};
    };
}

$ask = cookup ( @usages );
print $ask->("Lovey") . "\n";
cookup2 ( @usages );
print ask_monkey_about("Lovey") . "\n";
[download]

$/opt/perl5.16/bin/perl t15.pl 
Variable "%usd" will not stay shared at t15.pl line 11.
98
98
$
[download]

Both work, but I still get that warning. Maybe the interpreter is just telling me that %usd is not accessible outside of the cookup2 block? Or are there circumstances where my use of the "ask_monkey_about" subroutine will fail in some way?

Maybe this is an evolving behavior in Perl? Is this one of the reasons why there are versions two and three of the alpaca book?

Comment on anonymous vs named subroutines as closures Select or Download Code

Replies are listed 'Best First'.
Re: anonymous vs named subroutines as closures by chromatic (Archbishop) on May 31, 2013 at 19:46 UTC
Named subroutines have global visibility. They don't nest. When Perl compiles `ask_monkey_about`, there's no lexical named `%usd` in scope. Yes, the name exists and Perl knows about it, but Perl hasn't created the actual hash for `ask_monkey_about` to close over. That creation will only happen when something calls `cookup2` and Perl actually executes `my`. In the anonymous case, Perl creates the subroutine reference after it's run the `my` to create the lexical variable, which is the important difference. Named subroutines can indeed close over lexicals: `{ my %usd; sub ask_monkey_about { # do something with %usd } }` [download] ... but named subroutines don't nest.	[reply] [d/l] [select]
Re: anonymous vs named subroutines as closures by choroba (Cardinal) on May 31, 2013 at 19:45 UTC
No. The warning just means the nested sub keeps the value of the lexical variable from the first call of the parent sub: `#!/usr/bin/perl use warnings; use strict; sub init { my %h = @_; sub ask { my $q = shift; return $h{$q}; } } init( a => 1, b => 2); print ask('a'); # 1. init( a => 10, b => 20); print ask('a'); # Still 1.` [download] لսႽ† ᥲᥒ⚪⟊Ⴙᘓᖇ Ꮅᘓᖇ⎱ Ⴙᥲ𝇋ƙᘓᖇ	[reply] [d/l]
Re: anonymous vs named subroutines as closures by LanX (Saint) on May 31, 2013 at 20:44 UTC
you'll find excellent descriptions when searching for "will not stay shared" The essential problem is a) named subs are only created once b) but lexical closure variables are dynamic One way to get around this is `*ask_monkey_about =sub { my $cst = shift; $usd{$cst}; };` [download] and you get a named sub which is dynamically bound to its closure. Cheers Rolf ( addicted to the Perl Programming Language)	[reply] [d/l]
Re: anonymous vs named subroutines as closures by ikegami (Patriarch) on Jun 04, 2013 at 04:16 UTC
Demonstration of "will not stay shared": `sub outer { my ($x) = @_; sub inner { say $x; } inner(); } # Warns Variable "$x" will not stay shared outer(4); # Prints 4 outer(6); # Prints 4!!!` [download] Here's what's going on. `sub named { ... }` [download] is more or less the same as `BEGIN { *named = sub { ... }; }` [download] As such, it only captures once, when the sub is compiled. In the above code, when `outer` goes out of scope, `$x` would normally be cleared. But since the closure still references it, a new `$x` is a created instead. From this point on, the `$x` in `inner` is different from the `$x` is `outer`; it "didn't stay shared".	[reply] [d/l] [select]
Re: anonymous vs named subroutines as closures by Clovis_Sangrail (Beadle) on Jun 03, 2013 at 15:46 UTC
Thanks, these are all very helpful responses, and an interesting look 'under the hood' of Perl. (And the temptation to henceforth declare all my variables as typeglobs passed quickly :) )	[reply]