"Jonathan E. Paton" <[EMAIL PROTECTED]> 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?
Hmm... I'd hope croak would do the right thing without having to break
the tail call optimization. Personally, I think the best bet is to
alter caller's semantics slightly (in fact I think that the
optimization will make it more likely that caller(1) will return the
right thing.)
> 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.
Certainly will be slower in Perl 5. Hopefully what won't be the case
in Perl 6 (having had to recast code from tail recursive form
explicitly iterative form, I'd really rather not have to do that in
the general case.)
--
Piers
"It is a truth universally acknowledged that a language in
possession of a rich syntax must be in need of a rewrite."
-- Jane Austen?
