in reply to Re^3: Why is the execution order of subexpressions undefined? (basics)
in thread Why is the execution order of subexpressions undefined?

What if f or g affect $o? What order then?

Then, as TimToady put it:

you are implicitly promising that the parallel branches either A) don't have side effects, or that if they do, B) you don't think the side effects will interact, or C) the side effects are idempotent so it doesn't matter in which order they happen, or D) you just don't give a rip

Or as I put it:

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".

If there are interdependancies between f() and g(), for example, they modify $o in some way that precludes their being parallelised, then then programmer must not put them in the same statement.

my $rv1 = f( $o->next ); my $rv2 = g( $o->next ); my $x = $rv1 + $rv2;

No paralleisation is possible because they are no longer in the same expression.

Further, I'm not sure why you're only defining this for arguments to functions.

As stated, I have been restricting myself to the simplest possible case that demonstrates the possibility of parallelism, and the need for defined EO.

The mechanism does, by implication, extend to all sub expressions within expressions.

my $x = $i + ++$i;

Because ++$i involves a unary operator, it is a subexpression. With undefined EO, the programmer cannot know what this will produce, with defined EO he can. I'm not for one moment suggesting that it is a good thing to do in practice, but it demonstrates the point. But it is not a good example for the wider discussion because there is not scope for parallelism.

And in this:

$x = f( g() + h() ) * p( q() - r() );

has 3 points of possible paralellism. Each of g() & h(), q() & r() and f() & p().

And with defined EO, if h() has a dependancy on r(), and must be executed first, then I can write that as:

$x = p( q() - r() ) * f( g() + h() );

and know it will do the right thing. Without it, I have to write:

my $temp1 = p( q() - r() ); my $temp2 = f( g() + h() ); $x = $temp1 * $temp2;

and lose the oportunity for one level of parallelism. Or as:

$temp1 = q() - r(); $temp2 = g() + h(); $x = f( $temp2 ) * p( $temp1 );

Which anyway you cut it is less clear and more open to maintainance errors than the first one above.

I do not consider my definition of EO incomplete--for one thing, I haven't outlined what my definition would be--but the point remains that it can be whatever is required to achieve the desired effect. The point is that subexpression must be evaluated before the expression they are a part of. Once the complex expression is reduce to a simple expression, the rules can change, if that is what is required to achieve the result.

You say it is unintuative--which I take to mean that you cannot think of any other reason to oppose it--but you do not find the current Perl 5 "the compiler might do it this way or it might do it that way" intuative?

And I'm definitely not as tactful as TimToady

Strange, but I saw many confirmations of my position, though I agree not complete agreement, in his posts. Maybe I misread him, but much of the little he said echoed things I have been saying in this thread.

For now, I admit defeat--I am not going to change your mind and nothing I have seen here has changed mine. So, I'll stop right here.


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?