Front page | perl.perl5.porters |
Postings from December 2007
On Dec 31, 2007 9:56 AM, Aristotle Pagaltzis <pagaltzis@gmx.de> wrote:
>
> Huh? Tail recursion by definition means that there is no
> computation left in the calling function; the only reason it's
> still around is to wait for the callee's return value so it can
> pass it right up the call chain as its dying act. IOW:
>
> return foo( $bar, $baz ); # tail call
> return 10 + length $foo; # not a tail call
>
> The latter is no tail call because it needs to perform further
> computation with the return value before it can return it.
>
> So far this is basic stuff, and I assume you know this; I'm just
> repeating it to make sure we're on the same page, because I'm
> puzzled as to what computation could possibly happen in the
> (literal…) space between `return` and `foo(...)`. It seems to me
> that even in a dynamic language that has tieing, overloading etc
> there is no possible side effect that could be triggered at that
> point; if anything is to happen, it so will at the other end of
> the `return`.
>
> That's also how I understand context propagation to work.
>
> Am I wrong?
the things that happen differently in Perl with tail-return optimization
are that the call stack no longer has the parent frame in it, and
things declared in there will get destroyed, which might, for instance
with RAII, cause very strange effects.
Consider:
my $RAII_lock : flimsy = open_raii_lock();
return (something to do with the locked resource);
with a tail-return optimization, the lock would get released BEFORE
the critical section!
Tail-return optimization has
been available for a very long time, but it looks funny and you have to
do it yourself. I doubt it could be added as a transparent optimization
in a robust way due to the various edge and corner cases.
# tail call
shift while @_; # don't clobber previous frame's args
@_ = ( $bar, $baz );
goto &foo;
as a new piece of syntax that is less awkward though I'm all for it
Thread Next