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

Huh? Guess what? There's no guessing involved if you are going to write an expression that doesn't depend on the order of evaluation. Guessing is required if you write an expression that does, and you don't know the order because it's either not defined, or you can't memorize the table.

And which ones are they? Is that written down somewhere?

perlop, where else? It defines the order of execution for some operators, and doesn't define them for the rest. Assume the order of execution is defined when it's defined in the documentation, and assume the order of execution isn't defined when it isn't.

Doesn't sound like rocket science to me.

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

Indeed. For the same reason one might use parenthesis if you, or those who come after you, can't remember the 23 levels of precedence. In Perl6, it will be even worse, with even more operators.

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.

Of course, in practise, for the majority of the expressions, the order of evaluation doesn't matter. In print sin(3) + log(5), it doesn't matter whether I calculate the sin first, or the log first.

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.

Which, unless you can solve the halting problem, means, don't start evaluation the second expression before finishing evaluation the first. Which means no parallellism, so why bother with autothreading?

You're wrong.

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

Let's see, does that mean order of evaluation of subexpressions also matters if the subexpressions don't have side-effects, or does that mean not defining the order for at least one operator means you don't have order of evaluation at all? Because those where the things I claimed you were wrong.