Why do I claim that the following statement is parallelisable (if EO is defined)?

    my $result = func1( $a ) + func2( $a++ );
[download]

The simple answer is "Because there is nothing to prevent it!".

In the absence of defined EO, the compiler is theoretically free to process that line as follows:

1. Increment $a
2. Stack an alias to $a.
3. Call func2().
4. Returning from func2() leaves it's result on the stack.
5. Stack an alias to $a.
6. Call func1().
7. Returning from func1() leaves it's result on the stack.
8. Call add().
9. The result of Add() is left on the stack.
10. Add a variable $result to the pad and initialise it with the value popped from the stack.

Or, it could do that

1. Stack an alias to $a.
2. Call func1().
3. Returning from func1() leaves it's result on the stack.
4. Increment $a
5. Stack an alias to $a.
6. Call func2
7. Returning from func2() leaves it's result on the stack.
8. Call add().
9. The result of Add() is left on the stack.
10. Add a variable $result to the pad and initialise it with the value popped from the stack.

The results will be different, even without the possibility of either function modifying their parameter.

The value of $a will be different, dependant upon the unknowable order in which the compiler executes the code.

With EO undefined, the programmer cannot indicate the required order, and so must place the calls to func1() and func2() in separate statements, and that explicitly prevents the two functions being called in parallel.

With defined EO, there is only one possible sequence:

1. Place an alias to $a somewhere (for func1()).
2. Increment $a.
3. Place an alias to $a somewhere (for func2()).
4. * see below.
5. Invoke an asyncronous call to func1() also passing a semaphore.
6. Invoke an asyncronous call to func2() also passing a semaphore.
7. Wait until both semaphores clear.
8. Retrieve the results from func1() and stack.
9. Retrieve the results from func2() and stack.
10. Call Add().
11. The result of Add() is left on the stack.
12. Add a variable $result to the pad and initialise it with the value popped from the stack.

*Because there are no other dependancies or ambiguities, the compiler can know that (if they are parallelisable), it only needs the results from func1() and func2() in order to call Add(), so it is free to parallelise func1() and func2().

Because of defined EO, the programmer has explicitly indicated that there are no interdependancies between func1() and func2(), or if there are any interdependancies, he knows that they will "do the right thing".

The onus is on the programmer, and is completely within his control, and the compiler does not need to make that determination.

That is the salient point.

Without defined EO, the only control the programmer has over the order of execution is to use separate statements, but separate statements automatically precludes transparent parallelism.

With defined EO, the programmer is explicitly indicating that any two functions (methods) that are marked as being parallelisable, that appear in the same statement, as co-operands to a non-serialising operation, can be parallelised.

He is telling the compiler this by that placement. The compiler cannot make this determination without huge amounts of complex analysis, but the programmer can make that determination--IF EO is defined.

Without EO, it requires complicated extra syntax, which entirely negates the concept of transparent parallelisation.

You may argue that the concept of transparent parallelisation isn't usful--I'd say you where wrong, but that's a philosophical argument.

You may argue that extra syntax is the way to go--again, I will argue with you about that.

But if the concept is useful, and I strongly believe it is, then having a defined EO is an unarguable necessity.

I also happen to think that it will be seen to be a requirement for other parts of the Perl 6 syntax to work also, but that's still not completely clear.

I also think that as the supposed benefit of potentially improved efficency, through statement reordering, has never, and can never be realised, the only reason for not defining EO is a myth.

That leaves us with gaining a benefit from defining it and loosing nothing, or not defining it and not gaining something.

I do not see why people are arguing for retaining ambiguity for no gain.