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

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?
  • Comment on Re^38: Why is the execution order of subexpressions undefined? (magic ruts)

Replies are listed 'Best First'.
Re^39: Why is the execution order of subexpressions undefined? (magic ruts)
by TimToady (Parson) on Apr 16, 2005 at 23:32 UTC
    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.

      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?
        Yes, and with both hyperops and with junctions, 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.