If the execution order is undefined, the execution may happen in parallel. Considering the rise of the multi-CPU machines, there can be a nice performance gain by not defining execution order.

Funnily enough, that is exactly where my thoughts on the subject started. I was thinking about the parallelisation of code using threads.

However, I would counter contend that if execution order is undefined and a compound statement could be transparently threaded, then, given the non-determanistic nature of threading, it would not only be impossible to guess the outcome of a compound statement--it would vary from run to run!

Indeed, if autothreading (in the threads sense rather than the P6 sense (if they are not the same thing?)), is ever going to be possible, it would be necessary to define the order of execution if the outcome of a compound statement is ever going to be predictable.

IMO, the less code relies on execution order, the clearer the code is.

Were it written down exactly when evaluation order could affect the outcome of a statement, then it would be easy to avoid it--but it isn't.

Unless you're advocating never using compound statements?

In which case, you would have to remove autoincrement, autodecrement and all the <op>= compound assignment operators from the language.

You're wrong.

First of all, not defining the order in all cases doesn't mean no order should be defined at all. && and || would not be as useful as they are now if their order of evaluation (first left operand, then right operand) wasn't defined.

Secondly, order of evaluation of (sub)expressions only matters if the expressions have side effects, and the side effects influence the value of the other sub expressions. But if you have:

    sub fib {my $n = shift; $n <= 1 ? $n : $n + fib($n - 1)}
    sub fac {my $n = shift; $n <= 1 ?  1 : $n * fac($n - 1)}
    my $var = fib(3) + fac(4);
[download]

it really doesn't matter whether fib(3) or fac(4) is evaluated first.

Were it written down exactly when evaluation order could affect the outcome of a statement, then it would be easy to avoid it--but it isn't.

Huh? I don't get that. How is it easier to write an expression that isn't depending on the order of evaluation if the order of evaluation is defined? I mean, if you have:

    my $i = 1;
    sub f {$i += 1; $_[0] * $i}
    print f(2) + f(3);
[download]

then it's easier to avoid dependency on the order of evaluation if you know + causes its left hand side to be evaluated before its right hand side?

Unless you're advocating never using compound statements?

Not at all. Just don't write expressions which use operators whose order of evaluation isn't defined, but whose outcome does depend on the order of evaluation. For instance, my previous example could have been written as:

    my $tmp = f(2);
    print $tmp + f(3);
[download]

and now it doesn't matter which order + has.

Indeed, if autothreading (in the threads sense rather than the P6 sense (if they are not the same thing?)), is ever going to be possible, it would be necessary to define the order of execution if the outcome of a compound statement is ever going to be predictable.

So, you need order of execution to do things in parallel, but because there's an order of execution, two things can't happen in parallel?