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

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?

Replies are listed 'Best First'.
Re^42: Why is EO undefined? (More details!)
by Anonymous Monk on Apr 18, 2005 at 15:59 UTC
    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.
      I think the main problem is that BrowserUk doesn't have any practial experience with an actual concurrent language. That seems to be the root cause for most of the misunderstandings.
      A reply falls below the community's threshold of quality. You may see it by logging in.

      I'll concede one thing here--the 'can' or 'could' should have appeared within the seconds sentence, with respect to Perl--but it is valid as is for (some) other languages.


      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?