=?iso-8859-1?q?Jonathan=20E.=20Paton?= writes:
: > : Piers Cawley writes:
: > :
: > : So, here I am working on a Scheme interpreter in Perl 6, and I'm
: > : trying to write it in a (for want of a better description)
: > : 'Scheme-like' fashion with lots of recursion.
: > :
: > : The trouble is, unless Perl6 is going to be guaranteed to do
: > : optimization of tail calls, this is going to lead to horribly slow
: > : code. So, do I bite the bullet and recast some of the functions in an
: > : iterative vein, or do I trust that Perl6 will do tail call optimization?
: > :
: > : Larry?
: >
: > Larry Wall responds:
: >
: > Why not? The only casualty is caller()'s semantics, and I think we
: > can live with that, or disable the optimization on routines that use
: > caller().
:
: Carp.pm is implemented with caller(), does that mean:
:
: sub forever {
: my $depth = shift;
:
: croak "I got bored"
: if $depth == 1000;
:
: forever($depth + 1);
: }
:
: will have its optimizations disabled? Or is that fair game; considering you have to
:play a little
: more intimately with Carp to croak from the right place?
No, I don't thing calling something that uses caller should disable the
optimization. In fact, considering what croak uses caller for, it
would only make croak all the more efficient. croak uses caller to
search backward for who called into forever() in the first place, so
chopping out the recursion cuts its work down from O(n) to O(1).
: Mental note:
:
: 1. Don't use recursion in Perl, it'll be much slower than an iterative approach
: 2. If in doubt, refer to note 1.
Recursion is beautiful, but computers don't really grok beauty.
Larry
