On 6/13/05, Paul Johnson <[EMAIL PROTECTED]> wrote:
> On Mon, Jun 13, 2005 at 11:24:07AM +0000, Luke Palmer wrote:
> > Back when I wrote an
> > back-chaining system in perl, I used tied variables in order to
> > determine when I needed to solve for something. A standard idiom was:
> >
> > rule \$var, sub {
> > $a and $b and $c;
> > $var = 1;
> > };
> >
> > And damnit, $c would never be solved for, because it was optimized
> > away by Perl.
>
> I'm not sure that short circuiting operators can be called an
> optimisation. Aren't they more part of the language definition? I
> assume Perl 6 isn't doing away with short circuiting operators.
Oh, sorry, I was unclear. Perl 6 will not do away with
short-circuiting operators, of course. I meant that if $a and $b both
ended up being true, $c still would not be evaluated, because Perl
determined that I wasn't doing anything with the value once it was
returned.
> > To sum up, optimizations are nice, and it's nice to have optimizations
> > on by default for PR reasons, but you have to be able to turn them
> > off.
>
> One of the things that has been on the Perl 5 wishlist for a while is a
> way to turn off the optimisations, but really that would only be for the
> benefit of people and modules that mess with the op tree. Again, I
> submit that an optimisation that changes normal behaviour is broken and
> that, in general, programmers shouldn't need to worry about what
> optimisations are going on under the covers.
Yeah, but in a language with 'eval', and otherwise as dynamic as (or
moreso than) Perl 5, optimizations that don't change *somebody's*
semantics are hard to come by. Most optimizations give you speed
benefit at the loss of some flexibility. For instance, early binding,
which can have quite large benefits, but disables redefinition at
runtime.
Luke
