in reply to Re^37: Why is EO undefined? (More details!)
in thread Why is the execution order of subexpressions undefined?

The runtime doesn't need to figure anything out.

If both operands to any, non-serialising, binary operator are non-simple variables (there'd be no chance for concurrency if either is), and the methods which produce those operands are marked (by their authors) as being parallelisable, then the runtime can parallelise them.

The very fact that they are parallelisable and the programmer has placed them within the same (simple)expression, either side of a non-serialising operator, means that the runtime can call the threaded versions of both methods and wait for them both to complete before continuing.

But, for that to be workable, the programmer must be able to guarentee the execution order of the derivation of any parameters that will be passed to those two methods.

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
Lingua non convalesco, consenesco et abolesco.
Rule 1 has a caveat! -- Who broke the cabal?
  • Comment on Re^38: Why is EO undefined? (More details!)

Replies are listed 'Best First'.
Re^39: Why is EO undefined? (More details!)
by Anonymous Monk on Apr 18, 2005 at 15:01 UTC
    I think we are in violent agreement. Except where the entire universe calls this undefined order of execution, you call it defined order.

    That doesn't matter.

    Since both you, and the rest of the world are saying that you may only write: 

        EXPR1 OP EXPR2

    [download]
    if it doesn't matter whether EXPR1 or EXPR2 gets evaluated first.
[reply]
[d/l]
      Why are we even continuing this? It is more than a dispute over definitions of terms. BrowserUK refuses to see where the rest of us are comming from. He won't even admit that it is a valid point of view that undefined evaluation order is *a* correct manner of specifying parallelism.
[reply]
        It is more than a dispute over definitions of terms?

        Update: (One) spelling correction made.

        Most emphatically yes!

        If all expressions that could contain an opportunity for parallelism were simple expressions (operand1 op operand 2), then you would be correct that undefined EO wouldn't matter--but they are not.

        Once the expression is a compound expression, the defined EO is required to allow the programmer to construct the single expression that retains the parallelisable operation, whilst having control over any subexpressions that must be rendered before that parallelisation can occur.

        If the only recourse the programmer has to ensure the order of evaluation, is to break up the expression into separate statements, then the opportunity for parallelism is lost.

        You have to look at the entire picture. Without extra syntax, separate statements means serialisation. Compound expressions permit concurrency without extra syntax. But for that to succeed, the programmer need to be able to know exactly what the result of the compound expression will be--for sure. No ifs and buts--otherwise how can he make the required guarentee that "there are no side-effects, or if there are, I know they will do the right thing"?

        He can only make that guarentee if he knows that the compiler will do exactly what he has programmed--not arbitrarially decide to reorder parts of the compound expression,

        And the bottom line is--nothing is lost by EO being defined.

        Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
        Lingua non convalesco, consenesco et abolesco.
        Rule 1 has a caveat! -- Who broke the cabal?
[reply]
[d/l]

In Section Seekers of Perl Wisdom