At 01:22 PM 3/28/2001 -0800, Russ Allbery wrote:
>Dan Sugalski <[EMAIL PROTECTED]> writes:
>
> > I'm actually considering whether we even need to care what the
> > programmer's said. If we can just flat-out say "We may optimize your
> > sort function, and we make no guarantees as to the number of times tied
> > data is fetched or subs inside the sort sub are called" then life
> > becomes much easier.
>
>I am strongly in favor of that approach. I see no reason to allow for
>weird side effects in Perl 6. (Perl 5 would be a different matter, of
>course.)
Well, weird side effects can be rather useful to exploit. Not, mind, that I
can think of one in the case of sorting, bur that doesn't mean there aren't
any.
>Not only is it simpler to deal with, it's simpler to *explain*, and that's
>important.
True enough. This is a small subset of general optimizations. For example,
this:
$i = 0;
foreach (1..1000) {
$i++;
}
can be easily optimized to:
$i = 1000;
and most language implementations with any sort of optimizer will do this.
If $i isn't actually used after that point without another assignment it
might well be completely optimized away. With perl, though, this does
potentially unexpected things if $i is tied. Do we still optimize it away?
Do we only do it if we can tell that $i's not tied? Do we force the
programmer to explicitly note which variables are potentially tied with the
"my Dog $spot" syntax and assume that everything else is fair game? Can we
even do that in the face of runtime requires, dos, or evals? (Or does that
force a complete reevaluation of the optimized bytecode)
I think I need to go fetch my brain out from behind the bookcase again...
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
