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

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

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

    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]
      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.
[reply]
        This almost looks like it might be a new record for thread nesting depth at perlmonks. Anyone know of a deeper one?
[reply]

In Section Seekers of Perl Wisdom