Re^28: Why is the execution order of subexpressions undefined? (magic ruts)

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?

Comment on Re^28: Why is the execution order of subexpressions undefined? (magic ruts)

Replies are listed 'Best First'.
Re^29: Why is the execution order of subexpressions undefined? (magic ruts) by tye (Sage) on Apr 15, 2005 at 17:29 UTC
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	[reply]
A reply falls below the community's threshold of quality. You may see it by logging in.
Re^29: Why is the execution order of subexpressions undefined? (magic ruts) by Anonymous Monk on Apr 15, 2005 at 17:29 UTC
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.	[reply]
Re^30: Why is the execution order of subexpressions undefined? (magic ruts) by BrowserUk (Patriarch) on Apr 15, 2005 at 18:09 UTC
It's called tVMI (t stand for tiny or toy), it was started more than 2 years ago, and has gone through many false starts as I learn what is involved. Indeed, if you look through the list of threads that I have initiated here, including many that describe bugs I have found in Perl, they mostly come out of that project. The interpreter is being written in D, but I tend to try out ideas in Perl first, but that often leadsd me into little used area of perl--like LVALUE refs (which I use as a substitute for pointers) and the like. I'm currently trying to get to grips with making it do transparent threading which is where this thread started. If as and when I get something that successfully demonstrates the ideas, I will willing share it with anyone who is interested--if I knew who you were or had a way to contact you, I would do so. 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?	[reply]