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

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.

Replies are listed 'Best First'.
Re^40: Why is EO undefined? (More details!)
by Anonymous Monk on Apr 18, 2005 at 15:14 UTC
    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]
        Without extra syntax, separate statements means serialisation. Compound expressions permit concurrency without extra syntax.
        See. Right there. We're working off of a complete different set of assumptions. What in the world makes you think the above quote is true? Are you talking about a particular parallel language you haven't mentioned? (Is there a parallel/array dialect of Perl out there?) Because in the general case that statement is false, if for no other reason than it is overly general.
[reply]
          A reply falls below the community's threshold of quality. You may see it by logging in.

In Section Seekers of Perl Wisdom