But if EO is defined, then by putting the two function calls in the same statement, and ordering them the way they are

    $result = func1( $var++ ) op func2( $var );
[download]

the programmer is explicitly stating that they do not have interdependancies and *can* be run in parallel.

So, the point of having a defined EO is to allow the programmer to tell the compiler "the order of execution is defined here, so you're free to run it in parallel because it doesn't matter in which order they are executed"? But that would mean that if the order did matter, then you can't write the above expression. Despite the EO being defined.

Let's get a bit less abstract, and use a concrete example. Suppose EO is defined, and for binary operators, it's left to right. You have a function that reads a single line from stdin:

sub read_a_line {return scalar <STDIN>}
[download]

Now you want to use that function to get the next two lines. Since EO is defined, you might think it's safe to write:

my $two_lines = read_a_line() . read_a_line();
[download]

But by your statement, this tells the compiler the two function don't have interdependancies, and can be run in parallel. But that could mean the invocation on the right hand side might get the first line, leaving the second line for the invocation on the left hand side of the concatenation operator. And that means the statement should have been written as:

my $two_lines  = read_a_line();
   $two_lines .= read_a_line();
[download]

But that's how you write them if the EO is undefined.

If writing

    EXPR1 OP EXPR2
[download]

tells the compiler that there are no interdependencies between EXPR1 and EXPR2, and that the compiler is free to parallellize them, you are saying that the order of execution doesn't matter. And hence, it may as well be undefined.