in reply to Re^50: Why is EO undefined? (More details!)
in thread Why is the execution order of subexpressions undefined?

Now I think we might be getting somewhere (well, I think. I haven't been following all the threads here. We must be rapidy approching 200+). I know I've been confused, because sometimes you talk about implicit concurrency. But your statement "If he didn't want that to happen, he would not have placed them either side of a non-serialising operator" implies we are talking about explicit concurrency.

And that makes most of the discussion we've been having moot. (I'm sure you'll disagree, but an explicit concurrency operator is really an "undefine the evaluation order" operator for these expressions)

  • Comment on Re^51: Hallelujah [was: Why is EO undefined?]

Replies are listed 'Best First'.
Re^52: Hallelujah [was: Why is EO undefined?]
by BrowserUk (Patriarch) on Apr 18, 2005 at 23:08 UTC
    but an explicit concurrency operator is really an "undefine the evaluation order" operator for these expressions

    You're right, I do disagree :)

    The token 'op' was a placeholder for any non-serialising operation That is, not and, or, &&, ||, ',' or any operator where the existing semantics would force an evaluation order.

    Therefore, it could include +, -, *, /, **, ^, &, | etc. etc. Basically, any binary operator that doesn't impose an evaluation order of it's own.

    And I can only go back to my earlier examples. In

    func1( <expression(s) rendering the argument list1> ) + func2( <expression(s) rendering the argument list2> )

    the programmer needs to know what order the arguments will be evaluated in. He needs that so that he can put his hand on his heart and swear "I know about any and all side-effects that may occur as a result of deriving those argument lists, and I am happy that, done in the order I have specified, they will do the right thing".

    At that point, if func1() and func2() have any potential for parallelism, and have been marked as such by their authors, the compiler is free to invoke them in parallel, implicitly. Ie. without any further explicit authorisation through additional syntax.

    But without the knowledge of what order those argument lists will be evaluated, it isn't possible for the programmer to put his hand on his heart and so swear.


    By the by, I would also like a non-serialising comma-equivalent operator. One that says, the expressions either side of this operator are unrelated, but can be run in parallel. This would enable:

    my( $x, $y ) = ( $db->getData() >>,<< $lwp->getdata() );

    I don't expect that syntax to be acceptable to anyone, it's just the nearest thing to anything existing I could think of off the top of my head (although it does have some merit :)

    Or maybe that would be:

    while( my $x = $db->getData() >>and<< my $y = $lwp->getData() ) { ## Use $x and $y }

    But maybe that is already covered by junctions:

    while( all( my $x = $db->getData() & my $y = $lwp->getData() ) ) { ## use $x and $y }

    Be kind of neat if the problem of processing data from multiple files or multiple sockets could be reduced to

    while( my $messageObj = read( any( @sockets ) ) ) { ## reply send $msgObj->socket, "Thanks for your message '$msgObj->text', we'll get back to yo +u." }

    Kind of remeniscent of the 4-args select loop, but without the need for bit-twiddling.


    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?
Re^52: Hallelujah [was: Why is EO undefined?]
by Anonymous Monk on Apr 18, 2005 at 22:30 UTC
    And FWIW BrowserUk, that last post put me back in the camp of thinking you're not on crack. (But I still think you're mildly confused with some terminology, but a little more familiarity with concurrent languages will get up up to speed in no time)

      Geez. You mean that the money I just shelled out having the milk I put in my tea analysed for narcotic contamination was wasted :).

      Seriously, thankyou for posting that. It get's extremely disconcerting when you are so sure that what you're saying makes at least some sense, when all around you are pounding on you. That tiny piece of positive indication that I am not necessarially, totally barking mad, is much appreciated.


      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?

        Definitely not in Oz...

        We're building the house of the future together.