First of all, you did silently ignore my second, upper town example.

Because there is never any opportunity for transparent overlapping. The final results of the two chains (C & F), never come together.

All the compiler sees is two entirely unconnected sequences of operations. When written in the source code, one set will come before the other or vice versa. For the compiler to determine that some of those parts can be overlapped would require extensive analysis of all of those steps in order to ensure that there were no hidden interdependancies. This would require the hugely intelligent compiler that tye, rightly, dismissed as a possibility.

There have been some attempts to do this, and with an entirely side-effects free language (Haskell, OCAML etc.), and very, very compilcated compilers (eg. GHC), then you can perform that kind of analysis, but for Perl, which is not, and will not be, side-effects free, the analysis would have no boundaries. Every step could have an interdependancy upon a previous step, and that on a previous step and ultimately, the first two steps in any two apparently unconnected chains could share an interdependancy. That means that the compiler would have to reanalyse every step in every pair of dependancy chains, and that is the NP-complete/Halting problem.

That's why it must be the programmers that make these determinations. The authors of routines indicate that there is some scope within each routine for parallelisation.

The callers of those routines, decide whether the particular combination of two routines that the need to call at any given point in their code, if so marked by their authors, can be overlapped.

Bogus. If the execution order is left undefined, the programmer can still clearly indicate the order by moving out the expressions into different statements

But, as soon as you move the routines into separate statements, all opportunity for the compiler to overlap those routines is lost, unless the compiler is going to solve the Halting problem.

The only time the compiler can transparently decide to overlap the routines, is when the they produce the operands to a non-serialising operation. And that means that they must be in the same expression.

I'm sorry for all the emphasis and repetition, but it is so clear (to me), that there is a single sequence of logical steps in this conversation. If A is true, then B can be so. If B is true, then C is so. It feels to me when I am reading your posts that you keep considering one part in isolation of the rest and and drawing conclusions on that basis, but you have to consider the entire chain to see the full picture--just as the compiler would have to do in order to parallelise your Uptown sequence.

And at the basis of the whole thing, is this weddedness to an undefined EO, which serves no good purpose to start with. I simply do not understand why people continue to argue in support of something that has no benefits and only ever causes them extra work.