=?iso-8859-1?q?Jonathan=20E.=20Paton?= writes:
: 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.
Well, eval pessimizes a number of possible optimizations, but I don't
think it really needs to pessimize this one. Many uses of caller would
tend to appreciate not having to deal with recursion anyway. The only
possible exception I can think of is doing a stack trace in the debugger,
and most people would prefer to have the recursion compressed there
as well, I imagine. Maybe if tail recursion under the debugger was
smart enough to keep track of how deep the recursion was, that'd be
useful. But tail recursion tends to be data driven, so examining the
current arguments to the routine would typically tell the debuggor
how deep the recursion is even without the explicit count.
: =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...
Thanks, I love attention. :-)
: > > 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.
Except for constants.
Perl 6 should be much better in this regard, provided you make use of
the formal parameter syntax. The old way of setting up @_ with default
read/write parameters is one place that slows down Perl 5 subroutine
calls, so the newer signatures that default the argument list to being
constant should help the optimizer out a great deal, since it can then
just pull arguments straight from wherever they're stored, whether
stack or register. The JIT (which already exists!) will also help,
hopefully.
Larry
