<Moved from -language>
Ariel Scolnicov wrote:
> Nathan Torkington <[EMAIL PROTECTED]> writes:
> > $a and $b were done for speed: quicker to set up those global
> > variables than to pass values through the stack. The documentation
> > for perl5's sort function says that passing as arguments is
> > considerably slower. I don't think you can handwave and say "oh,
> > that's an implementation detail". I think it's an implementation
> > detail that's bloody hard to fix, especially for things like code
> > references passed to sort:
> >
> > sort $some_ref @unordered
> >
> > Perl can't do anything at compile-time to tell sort where lexicals
> > in the sort sub are.
>
> Then it doesn't have to. But if the sub is explicitly specified
> (maybe according to the easy-closure RFCs) then it *can* do it
> efficiently. In most cases I've seen, when a complex order criterion
> is used sort gets passed C<sort {complex_criterion($a,$b)} @list>, so
> we're saving little.
>
How much hand-waving can we do with implementation efficiency of anonymous
subs and higher order functions? How much can we expect Perl to optimise
away at compile time? For instance, if:
$sum = reduce ^_+^_, @list;
has any substantial overhead on each iteration it would be useless for any
decent sized number crunching. Other areas where this is a huge issue are
lazily generated lists (RFCs 81, 90, and 91), and implicit array loops (RFC
82). I've been kind of assuming that functions act on whole lists without
mutating them (RFC 82 operators, map, grep, reduce, ...) would be called in
a 'special way' that avoided the overhead of "real" sub calls. As I've
mentioned before, I've also put in various RFCs that this kind of stuff
should be evaluated lazily...
So anyway, if any of this is just so out of the question that we shouldn't
even consider the possibility, now is a great time to let us know!
> --
> Ariel "Glad I'm on -language and not on -internals" Scolnicov
>
--
Jeremy "Welcome to the pits of -internals" Howard :P
