Ah, I think I've finally got a glimse of what BrowserUk is smoking.

He appears to think that he can have subexpressions run in parallel by having the compiler know what the evaluation order is defined to be, and then instead of running the regular code in parallel (which can't guarantee evaluation order, obviously -- at least it is obvious to everyone but BrowserUk) but instead the compiler will analyse the code and run different code that will produce the same results as if the code were run in the defined order. (And he said it is impossible for a Perl optimizer to do some quite simple things, so I'm impressed that he thinks a Perl compiler can perform this astounding magic.)

Or, more likely, he is just stuck in a rut about how he is thinking about this and can't see that a few of his ideas just don't make any sense.

BrowserUk, you've dug into this argument too far. You aren't making sense and you should really take a break and come back to this with a less-tunneled view so you can hear several things that people have posted repeatedly (and either learn from them or respond to them in a way that addresses what was said -- and the latter would radically transform the field of computing, so good luck).

Thanks tye. You have seen a glimpse of where I'm heading--with caveats which I will get back to.

The problem with this discussion is that noone (except me) seems to recall how it started. I asked the question, why is the execution order of Perl (5) undefined. And the answer is: "There is no good reason!".

So then we move on to my suggesting why defining it-- for Perl 6. I'm not advocating any change to Perl 5--would be a good idea.

90% of the counter arguments conflate the two things.

We have people saying it doesn't need to be defined, because it is easy to avoid the problems that is undefinedness creates--but they completely ignore the fact that there is no good reason for it's undefinedness, so rather than needing to avoid the problems it creates (no matter how easy that is), we could define EO and those problems simply do not exist.

Then we have people making statements about what "programmers" collectively assume about defined EO--which is really what one (or two) programmers think having thought about it for 5 minutes.

What I am trying to suggest is radically different. I am saying that once you realise that undefined EO doesn't benefit Perl, that you can use that knowledge to think differently about what defined EO means.

I have been thinking, and coding, and researching this for a loong time, and the muddled, assumptive counter-arguments in this thread have served (me), by confirming my position--not weakening it. That I cannot seem to pursuade people to separate the "what is", from the "what could be" and apply logic rather than rhetoric, doesn't change my position.

I keep thinking that one person has made the transition in thinking--anonymonk2 almost got there--but then another person jumps in and re-covers old ground with the old arguments and their own set of assumptions and misunderstandings. This is not unusual when radical ideas are first proposed. Many a radical thinker has had to suffer the slings and arrows of entrenched dogma.

Now, getting back that glimpse you had.

the compiler will analyse the code and run different code that will produce the same results as if the code were run in the defined order

That's where you came up short. The whole point of requiring defined EO, is that it precludes the compiler from having to perform the analysis, because it allows the programmer to completely indicate what is and is not possible--using very clean syntax I might add, so I will.

... so I'm impressed that he thinks a Perl compiler can perform this astounding magic.

I do not understand that sentence. It implies that the Perl compiler (Perl 6 remember) has some limitations that "other compilers" do not have.

The Perl 6 compiler is going to have to exhibit a great deal of intelligence in order to deal with those things that are already accepted into the language. What happens when a junction is made shared and utilised on multiple threads? What happens when a shared junction is used as a formal parameter to a multi-method subroutine? Etc. etc. There are many areas of Perl 6 syntax that will make having an undefined EO require the programmer to explicitly serialise subexpressions in order to ensure that what he requires to happen, happens.

Defining the EO removes a burden of intelligence from the compiler, by placing the requirement upon the programmer.

Finally, if I could pursuade anyone to accept that last premise, then once the programmer has the tool of a defined EO in his possession, he can use that tool to convey extra information to the compiler that he cannot convey without it.

Your point appears to be that you believe that this thread has now gone on too long, so in deference, this will be my last post, but do not mistake my future silence for an acceptance that the ideas I've been trying to explain are defunct, they are not. They simply need a more receptive, less dogma entrenched forum for their exploration.

---

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?

Your point appears to be that you believe that this thread has now gone on too long

If that were my point, I wouldn't have said

or respond to them in a way that addresses what was said

You aren't succeeding at communicating. So take a break and come back to it.

You still appear to have something backward. Because defining the EO prevents the programmer from conveying anything to the compiler because then it doesn't matter how they write the code because it is all in defined order. Part of the point of EO being undefined is that it allows the programmer to say "this whole bit here, can be done in any order and it should still produce correct results because I don't need to have the order of evalation defined" (by using an expression) vs "this must be done in this order" (by using several statements).

And your complaint about people conflating Perl5 vs Perl6, I also see that as more of a problem in your head. Most of the arguments here for why EO should be undefined apply to both Perl5 and Perl6, but you are distracted by this conflation that you perceive and react to that and don't see the more important point of what was being said (it appears).

So, come back later (perhaps quite soon, depends how much of a break you need to get a fresh perspective) and reread the thread and try not to "insist" that people are missing the point when you read it. Then I think you'll be able to hear what is being said better and then can better respond to it so we can better understand you.

- tye        

I concur with the notion that we're stuck in a rut. BrowkerUK needs to code up a little interpreter for a tiny language which does all that he wants, before any further progress can be made on this front.

The subexpressions must be resolved to terms, before the expression containing op can be evaluated.

You're not making any sense. Forget about TERMs - they are irrelevant. Why does it matter whether we load $a from memory before $b in $a * $b? It can't. It can only matter when we're dealing with EXPRessions (or subexpressions or subsubexpressions - these are all still expressions), including, but not limited to, function or method calls.

In every case where defining EO will mean something to the developer, it means "serialisation" to the compiler. It's just that simple.

Defining EO restricts the perl VM to serial behaviour, leaving it undefined allows the VM the flexibility to parallelise some expressions. That is the answer to the original question. You have almost admitted it, although you probably don't see how you did. "With EO defined, there is no abiguity about what order those sub expression must be resolved." Exactly correct. Violent agreement. With EO defined, serialisation is a requirement. The logical negation of this is not that without defined EO, serialisation is not allowed, but that without defined EO, parallelism is permitted.

And there are a number of us who are looking forward to automatic parallelisation that is just simply possible with undefined EO, and is simply impossible with defined EO.