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.

In reply to Re^7: Why is the execution order of subexpressions undefined? by Anonymous Monk
in thread Why is the execution order of subexpressions undefined? by BrowserUk

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post, it's "PerlMonks-approved HTML":


  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.