Beefy Boxes and Bandwidth Generously Provided by pair Networks
Syntactic Confectionery Delight

anonymous vs named subroutines as closures

by Clovis_Sangrail (Beadle)
on May 31, 2013 at 19:24 UTC ( #1036300=perlquestion: print w/replies, xml ) Need Help??
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}; }; }

generates the ominous-sounding warning:

Variable "%usd" will not stay shared at 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 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";
$/opt/perl5.16/bin/perl Variable "%usd" will not stay shared at line 11. 98 98 $

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?

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 } }

    ... but named subroutines don't nest.

Re: anonymous vs named subroutines as closures
by choroba (Chancellor) 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.
    لսႽ ᥲᥒ⚪⟊Ⴙᘓᖇ Ꮅᘓᖇ⎱ Ⴙᥲ𝇋ƙᘓᖇ
Re: anonymous vs named subroutines as closures
by LanX (Chancellor) 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}; };

    and you get a named sub which is dynamically bound to its closure.

    Cheers Rolf

    ( addicted to the Perl Programming Language)

Re: anonymous vs named subroutines as closures
by ikegami (Pope) 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!!!

    Here's what's going on.

    sub named { ... }

    is more or less the same as

    BEGIN { *named = sub { ... }; }

    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".

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 :) )

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: perlquestion [id://1036300]
Approved by marto
and all is quiet...

How do I use this? | Other CB clients
Other Users?
Others contemplating the Monastery: (8)
As of 2017-02-21 17:18 GMT
Find Nodes?
    Voting Booth?
    Before electricity was invented, what was the Electric Eel called?

    Results (314 votes). Check out past polls.