I like.

It says everything I have been saying about the determinism of defined EO, the insecurity of undefined EO, and requirement for complicated compilers if they are to detect conflicting side-effects.

Now, rewrite the rules of what "defined EO" means.

Follow the traditional definition right up to the point where you end up with func1() op func2(). Traditionally with defined EO, func1() must be evaluated before func2(), but change that final step and say, because we got this far with defined EO, we are sure that everything we did to this point was done as the programmers wished it.

So, because the programmer got exactly what he asked for to this point, and func1() and func2() are both marked as being parallelisable, we trust his judgement and we'll go ahead and run func1() and func2() in parallel. No analysis...just do it because the programmer, knowing these modified rules, gave us carte blanche to do so.

If he didn't want that to happen, he would not have placed them either side of a non-serialising operator.

Now I think we might be getting somewhere (well, I think. I haven't been following all the threads here. We must be rapidy approching 200+). I know I've been confused, because sometimes you talk about implicit concurrency. But your statement "If he didn't want that to happen, he would not have placed them either side of a non-serialising operator" implies we are talking about explicit concurrency.

And that makes most of the discussion we've been having moot. (I'm sure you'll disagree, but an explicit concurrency operator is really an "undefine the evaluation order" operator for these expressions)

but an explicit concurrency operator is really an "undefine the evaluation order" operator for these expressions

You're right, I do disagree :)

The token 'op' was a placeholder for any non-serialising operation That is, not and, or, &&, ||, ',' or any operator where the existing semantics would force an evaluation order.

Therefore, it could include +, -, *, /, **, ^, &, | etc. etc. Basically, any binary operator that doesn't impose an evaluation order of it's own.

And I can only go back to my earlier examples. In

func1( <expression(s) rendering the argument list1>  ) 
+ 
func2( <expression(s) rendering the argument list2> )
[download]

the programmer needs to know what order the arguments will be evaluated in. He needs that so that he can put his hand on his heart and swear "I know about any and all side-effects that may occur as a result of deriving those argument lists, and I am happy that, done in the order I have specified, they will do the right thing".

At that point, if func1() and func2() have any potential for parallelism, and have been marked as such by their authors, the compiler is free to invoke them in parallel, implicitly. Ie. without any further explicit authorisation through additional syntax.

But without the knowledge of what order those argument lists will be evaluated, it isn't possible for the programmer to put his hand on his heart and so swear.

---

By the by, I would also like a non-serialising comma-equivalent operator. One that says, the expressions either side of this operator are unrelated, but can be run in parallel. This would enable:

my( $x, $y ) = ( $db->getData() >>,<< $lwp->getdata() );
[download]

I don't expect that syntax to be acceptable to anyone, it's just the nearest thing to anything existing I could think of off the top of my head (although it does have some merit :)

Or maybe that would be:

while( my $x = $db->getData() >>and<< my $y = $lwp->getData() ) {
    ## Use $x and $y
}
[download]

But maybe that is already covered by junctions:

while( all( my $x = $db->getData() & my $y = $lwp->getData() ) ) {
    ## use $x and $y
}
[download]

Be kind of neat if the problem of processing data from multiple files or multiple sockets could be reduced to

while( my $messageObj = read( any( @sockets ) ) ) {
    ## reply
    send $msgObj->socket, 
        "Thanks for your message '$msgObj->text', we'll get back to yo
+u."
}
[download]

Kind of remeniscent of the 4-args select loop, but without the need for bit-twiddling.

---

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?

And FWIW BrowserUk, that last post put me back in the camp of thinking you're not on crack. (But I still think you're mildly confused with some terminology, but a little more familiarity with concurrent languages will get up up to speed in no time)