Beefy Boxes and Bandwidth Generously Provided by pair Networks
more useful options
 
PerlMonks  

Is it possible to create a sub exclusive to a sub?

by punkish (Priest)
on Sep 18, 2004 at 23:51 UTC ( #392068=perlquestion: print w/ replies, xml ) Need Help??
punkish has asked for the wisdom of the Perl Monks concerning the following question:

Wise siblings, Since getting over embarrassment is the first step to learning, I admit here to not being able to answer the following -- Is it possible to create a subroutine exclusive to a subroutine? Conceptually speaking, I have --
lots of code .. .. sub foo { this; that; if (cond) { CODE: many lines of code here; } else { for (a loop) { something based on $_; CODE: many lines of code here; } } }
I want
lots of code .. .. sub foo { this; that; if (cond) { bar(); } else { for (a loop) { something based on $_; bar(); } } subsub bar { CODE: many lines of code here; } }

Comment on Is it possible to create a sub exclusive to a sub?
Select or Download Code
Re: Is it possible to create a sub exclusive to a sub?
by FoxtrotUniform (Prior) on Sep 19, 2004 at 00:10 UTC

    I played around with this a while ago, but not in any great depth. As far as I can tell, it's possible to declare a sub inside another sub block, but any named subs you declare are globally accessible symbols.

    If you want a truly local sub, your best bet is probably to build a closure lexically-scoped anonymous sub (thanks revdiablo):

    sub foo { this; that; my $bar = sub { # ... }; # EDIT: this semi needs to be here if(cond) { $bar->(); } else { for (a loop) { something based on $_; $bar->(); } } }

    It's cruftier than a local named sub, but it should do the trick.

    --
    F o x t r o t U n i f o r m
    Found a typo in this node? /msg me
    % man 3 strfry

      thanks for the reply. Looks like a neat trick, unfortunately, trying that gives me the error --
      Global symbol "$bar" requires explicit package name at...

        D'oh! My fault; the anonymous sub block needs to be delimited with a semicolon. Code changed.

        Here's a minimal example of what I think you're looking for:

        #! /usr/bin/perl -w use strict; sub foo { print "in foo\n"; my $bar = sub { print "in bar\n"; }; if(0 == @_) { $bar->(); } else { for (@_) { print "foo called with $_; "; $bar->(); } } } &foo(); &foo(qw(one two three));

        --
        F o x t r o t U n i f o r m
        Found a typo in this node? /msg me
        % man 3 strfry

        To make that work, you have to do what FoxtrotUniform did and declare and assign $bar before you use it, not afterwards as appears in the OP.

        You can, of course, declare subroutines within the block of other subroutines, but you will face two issues. One, as FoxtrotUniform mentioned, the sub is still global anyway. The other is that if the inner sub references any lexical variables declared in the outer sub, strange things will happen. Open up perldoc perldiag and look for the message "will not stay shared."

        Incidently, why do you want a sub sub? Is it so your sub can access private variables, or so your sub can use a routine name that may already be in use, or what? Just curious.
      If you want a truly local sub, your best bet is probably to build a closure

      Just a bit of clarification, a closure is not strictly necessary. What he wants is a lexically scoped, anonymous subroutine -- which is what you've demonstrated here. Whether that subroutine creates a closure is beside the point.

Re: Is it possible to create a sub exclusive to a sub? (Yes, and rare proper use of &$foo;)
by ihb (Deacon) on Sep 19, 2004 at 02:05 UTC

    You've been answered already that you should use an anonymous subroutine reference. I just want to tuck in that this is one of the very few cases where it's proper to exploit the behaviour of &$foo;.

    Abstracting a block of code in a subroutine into another subroutine makes you not able to use @_ directly--or does it?

    If you use the sigil & and no parenthesis in a subroutine call no new @_ will be created. The current @_ will be used. This is not the same as just passing @_ in the subroutine call. shift() and friends inside the called subroutine will effect the caller's @_ since they're the same. Thus, you get almost a macro-like solution.

    This means that exploiting this behaviour is perfect for sub subroutine-level code refactoring.

    You should never do &$foo; unless you know why and have a good reason. Here, you have a good reason and hopefully know why. :-)

    ihb

    Read argumentation in its context!

Re: Is it possible to create a sub exclusive to a sub?
by dragonchild (Archbishop) on Sep 19, 2004 at 02:07 UTC
    Incidentally, this mechanism is a really neat way to create a recursive subroutine. BrowserUk, AFAIK, was the first to post it on PerlMonks. (I'm just too lazy to link to the post.) Using Fibonacci numbers as the example:
    sub fibonacci { my $_fibo; $_fibo = sub { my $v = shift; $v > 1 ? $_fibo->($v - 1) + $_fibo->($v - 2) : 1; }; $_fibo->( @_ ); }

    I personally write all my recursive code like this.

    ------
    We are the carpenters and bricklayers of the Information Age.

    Then there are Damian modules.... *sigh* ... that's not about being less-lazy -- that's about being on some really good drugs -- you know, there is no spoon. - flyingmoose

    I shouldn't have to say this, but any code, unless otherwise stated, is untested

      Yes, stacks of nested subs are super-cool. But, uh, why bother writing all recursive code this way? I don't see any gain in efficiency (if anything, creating all those subs might slow things down a tad), and it introduces an extra level of "WTF?" to people reading the code.

      On the other hand, if you're writing tail-recursive code, this is a great way of not exposing an accumulator variable to the rest of the world. For example (untested):

      sub fact { my $fact_tr; # needs to exist before it gets assigned to $fact_tr = sub { my ($v, $r) = @_; return 1 if $v < 2; # oversimplified $fact_tr->($v-1, $v * $r); }; # thanks ihb for pointing out the missing semi $fact_tr->(@_, 1); }
      Also, have a look at Just Another Godel, Escher, Bach hacker.

      Edit: Separated declaration and use of $fact_tr. Thanks ihb!

      --
      F o x t r o t U n i f o r m
      Found a typo in this node? /msg me
      % man 3 strfry

      What I don't like about having anonymous subroutines that aren't closures inside subroutines is that the anonymous subroutine is created for each invocation of the surrounding subroutine. In your examples that means that each time &fibonacci is executed, a new recursive subroutine is created. Having anonymous recursive subroutines that aren't closures is even worse. Rephrase: Writing recursively defined subroutines that doesn't use the surrounding lexical scope as lexical anonymous recursive subroutines is even worse, since it creates a "circular closure". $_fibo in our example above is a circular reference and a very bad such since you can't break the circle manually. That's a pretty nasty memory leak.

      I would prefer to define the recursive subroutine once, rewriting your example to

      { my $_fibo; $_fibo = sub { my $v = shift; $v > 1 ? $_fibo->($v - 1) + $_fibo->($v - 2) : 1; }; sub fibonacci { $_fibo->(@_) } }

      ihb

      Read argumentation in its context!

        Aside from the obvious fact that you don't need a recursive routine to do a fibonacci sequence, I'm still wondering why anonymous subs would ever be preferable to named subs. Is there a measurable speed increase when calling a sub through a pointer rather than a name? Why not just do:
        sub fibo { my $inp = shift; $inp > 2 ? &fibo($inp - 1) + &fibo($inp - 2) : 1 }
        (for the sake of simplicity, this has been coded so that the nth term IS the nth term)

        1) 1
        2) 1
        3) 2
        4) 3

        Fair enough - defining the subroutine multiple times could be ... annoying. I'll definitely look at that modification.

        I'm still not certain about the memory leak part of it, especially the part when you say the anonymous sub isn't a closure. Could you explain that more?

        ------
        We are the carpenters and bricklayers of the Information Age.

        Then there are Damian modules.... *sigh* ... that's not about being less-lazy -- that's about being on some really good drugs -- you know, there is no spoon. - flyingmoose

        I shouldn't have to say this, but any code, unless otherwise stated, is untested

      288339 (again:)


      Examine what is said, not who speaks.
      "Efficiency is intelligent laziness." -David Dunham
      "Think for yourself!" - Abigail
      "Memory, processor, disk in that order on the hardware side. Algorithm, algorithm, algorithm on the code side." - tachyon

      With regards to the memory leak issue in Re^2: Is it possible to create a sub exclusive to a sub? (nasty memory leak) I thought I also should suggest a solution for those recursive subroutines that need to be a closure because it needs access to its lexical surrounding.

      First I want to emphasize that this is only needed when you need the recursive subroutine to have access to the lexical surrounding. I've very rarely needed that, and my personal style if I need a wrapper subroutine &foo (to e.g. supply default arguments to accumulators ) is to is to just name the recursive subroutine that does the work &_foo_rec.

      If you do as in Re: Is it possible to create a sub exclusive to a sub? but using a global datatype you don't create a circular reference. The problem with this solution is that the subroutine won't work right outside the lexical scope it was created in, something that's rarely needed for the problem you're solving above. If you both need to access the lexical surrounding and need to use it outside its lexical surrounding you can do the bit cumbersome

      use vars qw/ $REC /; my $_foo = sub { ... ; ... $REC->(...) ... ; ... ; }; my $foo = sub { local $REC = $_foo; $_foo->(@_); };
      and use $fac however you like from wherever you like. The $_foo subroutine is the actual subroutine but to make it safe and always work you need to first set $REC before calling it. That's what the wrapper subroutine in $foo is for.

      If you don't need to use the recursive subroutine outside its lexical scope you can do any of the following:

      sub foo { no warnings 'redefine'; local *foo = sub { ... ; ... foo(...) ...; ... ; }; return foo(@_); }
      This redefines the subroutine itself and that should be OK since the recursive subroutine probably never wants to use the wrapper subroutine. If this isn't good enough you may use
      use vars qw/ $REC /; sub foo { local $REC = sub { ... ; ... $REC->(...) ...; ... ; }; return $REC->(@_); }
      which is totally safe. As you see, you may have a reused global variable called $REC or whatever that you always use for the local recursive subroutines.

      The last suggestion above brings the thought to a favourite of mine: &_!

      sub foo { no warning 'redefine'; # needed if the recursive sub calls any + other sub local *_ = sub { ... ; ... _(...) ...; ... ; }; return _(@_); }
      To my great joy Larry realized the coolness of having a "current subroutine subroutine" and &_ will automagically be available for all subroutines in Perl 6!

      Update: Added solution for subroutines that both need to access the lexical surrounding and need to be used outside its lexical surrounding.

      ihb

      Read argumentation in its context!

Re: Is it possible to create a sub exclusive to a sub?
by Anonymous Monk on Sep 19, 2004 at 06:31 UTC
    perldoc -f sub
    perldoc perlsub
Re: Is it possible to create a sub exclusive to a sub?
by Aristotle (Chancellor) on Sep 19, 2004 at 07:38 UTC

    Update: ihb pointed this out before I did.

    All of the other solutions so far create the anonymous sub inside the calling sub, so they recreate it on every call. A better way that avoids that wasted effort would be

    BEGIN { my $bar = sub { # ... }; sub foo { # ... $bar->( $baz ); # ... $bar->( $quux ); # ... } }

    The BEGIN avoids a trap for the unwary: you might otherwise call foo() before the assignment to $bar has run, blowing up the script. If this code is in a module, there is an implicit BEGIN around all of the code, so this might not be necessary (your call), but it's a good defensive habit nonetheless.

    Makeshifts last the longest.

Re: Is it possible to create a sub exclusive to a sub?
by BrowserUk (Pope) on Sep 19, 2004 at 09:58 UTC

    Here's a way that avoids re-creating the local sub every invocation of the main, and avoids namespace pollution in main. It also allows as many (named) "local" subs as required.

    #! perl -slw use strict; sub test{ ## create a 'local' sub the first time we're called ## As many as you like each with it's own name *test->{localsub} = sub{ print 'localsub1'; return 12345; } unless exists *test->{localsub}; ## use it *test->{localsub}(); } print test; ## It's not truly local, but no namespace pollution. ## Anyone doing this, is doing it deliberately *test->{localsub}(); __END__ P:\test>test localsub1 12345 localsub1

    Examine what is said, not who speaks.
    "Efficiency is intelligent laziness." -David Dunham
    "Think for yourself!" - Abigail
    "Memory, processor, disk in that order on the hardware side. Algorithm, algorithm, algorithm on the code side." - tachyon

      That's just obfuscated syntax for

      sub test { $::test{localsub} = sub { print 'localsub1'; return 12345; } unless exists $::test{localsub}; $::test{localsub}->(); }

      and implies all the usual ramifications of global variable use.

      Makeshifts last the longest.

        The only "global variable use", it *main::test, which is in use anyway and has several slots going free. And I guess obfuscated is in the eye of the beholder.


        Examine what is said, not who speaks.
        "Efficiency is intelligent laziness." -David Dunham
        "Think for yourself!" - Abigail
        "Memory, processor, disk in that order on the hardware side. Algorithm, algorithm, algorithm on the code side." - tachyon

        *test->{localsub} isn't equivalent to $::test{localsub} in the general case. It just happens to be that in the current package in the code BrowserUk wrote. You probably know that, but I just want to point out that. It's important to realize that *foo doesn't by any means imply the main namespace.

        ihb

        Read argumentation in its context!

Re: Is it possible to create a sub exclusive to a sub?
by bsdz (Friar) on Sep 19, 2004 at 10:19 UTC
    One could implement something using the caller builtin, i.e. :-
    use strict; &foo; &badfoo; sub foo { &bar; } sub badfoo { &bar; } sub bar { if ((caller(1))[3] ne 'main::foo') { die((caller(0))[3], ": can not be called from ", (caller(1))[3], " due to restrictions"); } print "called sub ",(caller(0))[3], "\n"; }
    Update: changed "print STDERR" to "die"

      I think you indeed missed the point a bit. The idea isn't to prohibit people from calling it (althought you do by using the other solutions too). The idea is mainly to not pollute the global namespace.

      ihb

      Read argumentation in its context!

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: perlquestion [id://392068]
Approved by Old_Gray_Bear
Front-paged by grinder
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others exploiting the Monastery: (10)
As of 2014-07-10 20:22 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    When choosing user names for websites, I prefer to use:








    Results (215 votes), past polls