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->();
    }
  }
}
[download]

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

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.

thanks for the reply. Looks like a neat trick, unfortunately, trying that gives me the error --

Global symbol "$bar" requires explicit package name at...
[download]

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));
[download]

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

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

    $_fibo->( @_ );
}
[download]

I personally write all my recursive code like this.

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);
}
[download]

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->(@_) }
    }
[download]

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
}
[download]

(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

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->(@_);
    };
[download]

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(@_);
    }
[download]

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->(@_);
    }
[download]

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 _(@_);
    }
[download]

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!

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

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!

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 );
        # ...
    }
}
[download]

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.

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
[download]

That's just obfuscated syntax for

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

and implies all the usual ramifications of global variable use.

Makeshifts last the longest.

*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!

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

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";
}
[download]

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!

perldoc -f sub
perldoc perlsub