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?

It doesn't. I just means you do not have to guess.

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.

And which ones are they? Is that written down somewhere? I think we both know it isn't.

For instance, my previous example could have been written as:

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

So, you are advocating never using compound statements. Or at least, never using them if they order of evaluation could affect the outcome.

Except that you haven't told us when that is, so that amounts to the same thing. Don't use them--introduce a bunch of unnecessary temporary variables and increase the risks of inadvertant interspersion--or, try everything both ways and hope that "future enhancements" don't change things. Except, if they are never going to change, why leave them undefined in the first place?

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?

No. If the execution order is defined, then it becomes possible for the programmer to write code knowing what that execution order is. And in autothreading ever makes it into the language, the compiler can generate the required locking to ensure that syncpoints are generated to match the programmers syntactically defined requirements. Without a defined order, the compiler can only guess what the programmer meant, and the programmer can only guess what the compiler will do.

You're wrong.

I may be, but nothing in your post supports that conclusion, and much of your post confirms the contrary.