in reply to Re^36: Why is the execution order of subexpressions undefined? (magic ruts)
in thread Why is the execution order of subexpressions undefined?

We are still not communicating. You are actively ignoring the one fact that my two examples highlight. EO enforces an execution order. That is, all lists you will ever see, will be of the lower town kind. While, with undefined EO, you will also see lists of the kind that the upper town example has. And there is no need for them to come together. Which is the central point, at least to me. That you dismiss this means that you are talking about something completely different, or have a position/outlook completely different from mine. But as this discussion has now taken a depth of 37 levels, and people certainly smarter than I haven't conveyed their understanding to me, I'll leave it at that - sorry for not communicating my view better.

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

Replies are listed 'Best First'.
Re^38: Why is the execution order of subexpressions undefined? (magic ruts)
by BrowserUk (Patriarch) on Apr 16, 2005 at 19:52 UTC

    Okay. Well thanks for trying.

    You may have gathered, this is something I'm passionate about. I want to talk about it. I want to find the flaws and explore the possibilities.

    I have seriously considered your Downtown/Uptown examples, and to my mind, explained their lack of relevance.

    I would like to respond and explore the conclusions in your post to which I am replying, but I will respect your request to leave it at that.

    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]
      Okay, believe it or not, I read all of this back and forth, and I'm not going to join one side or the other. My takehome from this is that "Standard Perl 6" has three categories of operator:
      • Operators that require serial semantics, such as &&
      • Operators that require parallel semantics, such as junctions and hyperoperators
      • Operators that mandate neither, because we obviously don't all understand the problem yet
      However, I would point out that "Standard Perl 6" exists only down to the first declaration that mutates the language. So it would be entirely reasonable to have a pragma that gives whatever hints it it is felt might aid the compiler in whatever activity the compiler chooses to engage. If it turns out that giving the compiler more information about execution order helps rather than hinders the optimization of parallel routines, I'm sure that such a pragma will become very popular, possibly to the extent of being incorporated into the base language. Otherwise, not.
[reply]
[d/l]

        Thanks for taking the time, sorry it got so verbose. It really did start out as a simple question.

        I completely agree with your categorisation and accept that nothing is yet fixed in stone. I think that I have remembered to say that it isn't yet clear whether Perl 6 would need defined EO in order for those parts of the syntax and semantics that are already fairly well described. I think that at least some of them will, but that's just my speculation.

        I do have one question. Isn't it the case that any non-serialising, binary operator can be converted into a parallel operator using the hyper-thingies  >>op<<?

        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]
[d/l]

In Section Seekers of Perl Wisdom