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
| [reply] [Watch: Dir/Any] [d/l] |
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
| [reply] [Watch: Dir/Any] |
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)
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)
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! | [reply] [Watch: Dir/Any] [d/l] [select] |
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, ...
That makes no sense to me, but I have a fuzzy definition of Perl's closures, so that may not be surprising.
The confusing part is this.
{
my $foo = 1;
sub get_and_inc_foo { $foo++ }
}
I was always told that get_and_inc_foo() is a closure over $foo. But, it's neither anonymous nor lexical, so how does that work?
If my example is a closure, then aren't all subroutines closures over the file-scoped lexicals in the file they're defined in?
(Now that I think of it, isn't this the reason why you cannot have globals when using ModRegistry?)
------
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
| [reply] [Watch: Dir/Any] [d/l] |