> >> : Piers Cawley writes:
> >> : ...
> >> : 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().
Anything that touches string evaluation (Perl5's eval"") could harbour
caller(), this wouldn't matter unless there was a way to proprogate
exceptions out of an eval"" - and I bet someone already has the
appropriate RPC written.
=head Taking of pragmas...
I spotted another ape returning values from functions using package
globals. Can we have another strict type:
use strict 'asylum';
should stop programmers trying that one ;-)
=cut
> > 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.)
And all eyes are now on Larry...
> > 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.)
Will function calls be faster in Perl 6, in general? Using a simple
benchmark, an empty subroutine called with no arguments took around
1500 machine cycles to execute on Perl 5. Surely a nice new JIT and
better VM should make function calls less expensive, tight loops in
general are a bad idea in Perl 5 - no inlining.
Jonathan Paton
__________________________________________________
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com
