Nathan Torkington <[EMAIL PROTECTED]> writes:
> Piers Cawley writes:
> > > > The $a and $b of the sort comparator were A Bad Idea to begin with.
> > >
> > > Ditto. Can we ditch these in Perl 6? Don't see why $_[0] and $_[1] can't
> > > be used, or even a more standard $1 and $2. Either one makes it more
> > > obvious what's being operated on.
> >
> > $1 & $2 could be somewhat dangerous in a sub that might have regexen
> > in it...
>
> $1 and $2 are a poor choice because of regexps.
>
> $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.
Document that if you're "too clever" then you lose speed (for a
suitable value of "too clever"). But at least make the simple cases
easy.
> So I don't have a solution, I just have more detail on the problem.
--
Ariel "Glad I'm on -language and not on -internals" Scolnicov
