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]

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

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

you say the anonymous sub isn't a closure

Indeed I did. I expressed myself poorly and I've rephrased my post to hopefully better express what I meant.

(But first, to avoid any confusion: a closure is a subroutine, named or anonymous, that binds its lexical context.)

A lexical anonymous recursive subroutine is by necessity a closure. What I meant was that the subroutine, if written as a named subroutine, isn't a closure. By making it lexical and anonymous you make it one though, but the only lexical surrounding it is using is its own declaration.

The memory leak comes from that inside the subroutine, you use $_fibo. That makes $_fibo reference a subroutine that references $_fibo. Thus, $_fibo is a circular reference and refcount will never drop below two and won't be garbage collected.

This below illustrates what I've just said. On my perl, and probably yours too, the following will print the same for each iteration.

    sub foo {
        my $foo;
        $foo = sub { };
        print $foo;
    }

    for() for 1 .. 5;

    __END__
    CODE(0x1823d78)
    CODE(0x1823d78)
    CODE(0x1823d78)
    CODE(0x1823d78)
    CODE(0x1823d78)
[download]

This is because $foo gets garbage collected and the memory slot may be is currently is reused. (Since this just happens to be the implementation you can't trust it to always perform the same though.)

If you change the subroutine to bind $foo you get

    sub foo {
        my $foo;
        $foo = sub { $foo };
        print $foo;
    }

    for() for 1 .. 5;

    __END__
    CODE(0x274f7c)
    CODE(0x274da8)
    CODE(0x1823e48)
    CODE(0x1823e90)
    CODE(0x1823ed8)
[download]

Here we see that the memory slot isn't being reused.

It can also be interesting to look at the output of the &Dump subroutine in the Devel::Peek package. (For extra effect, dump the sub after doing differently many recursive calls.)

I hope I managed to express myself better this time.

ihb

Read argumentation in its context!

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]

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]

    use vars qw/ $REC /;
    sub foo {
        local $REC = sub {
            ... ;
            ... $REC->(...) ...;
            ... ;
        };

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

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]

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