http://qs1969.pair.com?node_id=289310


in reply to Re: Order of operations, mutators, aliasing and whammies
in thread Order of operations, mutators, aliasing and whammies

I disagree with the last piece of advice. Perl does have a defined order of evaluation; it is just not the same as your (or my) assumptions. Imagine that Perl did not have such a defined order of evaluation. How can I trust
print 5+1;
always prints 6, and not 5 (and a warning)?

update: I see that I was confusing precedence and evaluation order.

Replies are listed 'Best First'.
Re: Order of operations, mutators, aliasing and whammies
by Abigail-II (Bishop) on Sep 05, 2003 at 21:31 UTC
    Perl does have a defined order of evaluation;

    Do you know something that neither p5p nor comp.lang.perl.misc knows? Order of evaluation has been discussed recently on both forums, and noone one these forums has been able to show that Perl has a defined order of evaluation. Please quote the relevant parts of the documentation that define order of evaluation in general. (Order of evaluation is defined for &&, ||, and, or and comma in scalar context, but not generally).

    How can I trust
    print 5+1;
    always prints 6, and not 5 (and a warning)?

    Precedence garantees that. Just like C, Perl does have well defined precedence and associativity rules. But neither language has a defined order of evaluation.

    Abigail

      This one thing amazes me. ML is functional (though not purely), side-effects are pretty rare there, yet it does specify the order of evaluation in all cases. C and Perl are full of side-effects, yet they don't.

      Jenda
      Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live.
         -- Rick Osborne

      Edit by castaway: Closed small tag in signature

        Not defining order of evaluation leaves more possibilities open for optimalizations. Consider for instance the expression:
        f ($a) + g ($a)
        If you define an order of evaluation, it would probably be:
        • fetch the value of $a
        • call f() with $a as argument, remember the return value
        • fetch the value of $a
        • call g() with $a as argument, remember the return value
        • add the return values of f() and g().
        Notice the twice fetching of $a. If the order of evaluation isn't defined, you can first fetch the value of $a twice. Even if you do fetch the value twice (instead of fetching it once and remembering the results), doing it before calling f() and g() could be a win due to an increased chance of cache hits. It will also give you the opportunity to evaluate sub expressions in parallel.

        Last but not least, if the order of evaluation is defined, people will start writing code that depends on this. This will lead to fragile code, that will break if you swap the arguments of an otherwise symmetric operator.

        Finally, I don't see how lazy evaluation and a defined order of evaluation combine to a happy programming language. Perl6 will have a defined order of evaluation, and have lazy evaluation. I wonder how Larry is going to pull off that one.

        Abigail