Beefy Boxes and Bandwidth Generously Provided by pair Networks
The stupid question is the question not asked
 
PerlMonks  

Re^2: Why is the execution order of subexpressions undefined?

by BrowserUk (Patriarch)
on Apr 12, 2005 at 03:38 UTC ( [id://446827]=note: print w/replies, xml ) Need Help??


in reply to Re: Why is the execution order of subexpressions undefined?
in thread Why is the execution order of subexpressions undefined?

The order of evaluation is undefined within the C spec, thus it's undefined within the Perl spec.

I understand the reasoning behind this decision in C, but my question really centres upon one word in the sentance I quoted above: "thus". The most salient definition of that word in relation to that sentance is:

Therefore; consequently:

Does it follow that because code could be made more efficient at the C-level by not defining execution order, that the same would be true for Perl? Given that most of not all Perl opcodes are fairly heavy relative to the equivalent C code, I wonder if there is any real scope for improving efficiency at the Perl level by not defining execution order.

Ultimately, I wonder if Perl 6 could define an execution order without penalty? And whether that would be a good thing to do in terms of the usability and teh principil of least surprise?


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?

Replies are listed 'Best First'.
Re^3: Why is the execution order of subexpressions undefined?
by dragonchild (Archbishop) on Apr 12, 2005 at 12:34 UTC
    I personally agree with you that the order of subexpression evaluation could be defined in all cases, within Perl. (Heck, I think it could be defined now within C, as well.) But, I think tye has a very good point - who's going to go through the work of defining them? I certainly don't want Larry, Damian, Alison, or anyone on the P6L team doing it for P5. Maybe, this could be your big contribution to P6, but I'd get Larry's signoff on it, first. (Or, at the very least, run it past him and hope he doesn't deep-six the idea.)

      As far as I can tell from how my thinking on the problem has gone, there is only one situation where execution order can affect the outome of a statement. That can be summarised as:

      Any statement where a single variable is referenced twice or more, and where one of the references is as an lvalue and the lvalue reference come before another reference, can be subject to an evaluation order dependancy.

      The major culprits from what I can divine/remember are autoincrement and autodecrememt, but it obviously includes assignment.

      I think that the rule I suggested to Tye, that subexpressions are evaluated first; then precedence order; then left to right within precedence order. pretty much covers the entire definition.

      But I also think that defining that parenthesised subexpressions will always be evaluated before the expressions they form a part of, and that multiple subexpressions will be evaluated left to right is the major part. Indeed, I think that this reflects current practice, and that defining it would simply formalise that. There may be exceptions, but I am not aware of any--yet! :)

      This formalisation would allow the programmer to define the order in which they want compound expressions to be evaluated and place the responsibility firmly upon their shoulders--but give them the tool to get it right, for sure.

      I haven't gotten to do much with pugs yet, but maybe it will fall out of 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?
Re^3: Why is the execution order of subexpressions undefined?
by Anonymous Monk on Apr 12, 2005 at 13:08 UTC
    Ultimately, I wonder if Perl 6 could define an execution order without penalty?
    Actually, I wouldn't surprised if the execution order becomes more undefined in Perl6. If the execution order is undefined, the execution may happen in parallel. Considering the rise of the multi-CPU machines, there can be a nice performance gain by not defining execution order.

    IMO, the less code relies on execution order, the clearer the code is.

      If the execution order is undefined, the execution may happen in parallel. Considering the rise of the multi-CPU machines, there can be a nice performance gain by not defining execution order.

      Funnily enough, that is exactly where my thoughts on the subject started. I was thinking about the parallelisation of code using threads.

      However, I would counter contend that if execution order is undefined and a compound statement could be transparently threaded, then, given the non-determanistic nature of threading, it would not only be impossible to guess the outcome of a compound statement--it would vary from run to run!

      Indeed, if autothreading (in the threads sense rather than the P6 sense (if they are not the same thing?)), is ever going to be possible, it would be necessary to define the order of execution if the outcome of a compound statement is ever going to be predictable.

      IMO, the less code relies on execution order, the clearer the code is.

      Were it written down exactly when evaluation order could affect the outcome of a statement, then it would be easy to avoid it--but it isn't.

      Unless you're advocating never using compound statements?

      In which case, you would have to remove autoincrement, autodecrement and all the <op>= compound assignment operators from the language.


      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?
        You're wrong.

        First of all, not defining the order in all cases doesn't mean no order should be defined at all. && and || would not be as useful as they are now if their order of evaluation (first left operand, then right operand) wasn't defined.

        Secondly, order of evaluation of (sub)expressions only matters if the expressions have side effects, and the side effects influence the value of the other sub expressions. But if you have:

        sub fib {my $n = shift; $n <= 1 ? $n : $n + fib($n - 1)} sub fac {my $n = shift; $n <= 1 ? 1 : $n * fac($n - 1)} my $var = fib(3) + fac(4);
        it really doesn't matter whether fib(3) or fac(4) is evaluated first.
        Were it written down exactly when evaluation order could affect the outcome of a statement, then it would be easy to avoid it--but it isn't.
        Huh? I don't get that. How is it easier to write an expression that isn't depending on the order of evaluation if the order of evaluation is defined? I mean, if you have:
        my $i = 1; sub f {$i += 1; $_[0] * $i} print f(2) + f(3);
        then it's easier to avoid dependency on the order of evaluation if you know + causes its left hand side to be evaluated before its right hand side?
        Unless you're advocating never using compound statements?
        Not at all. Just don't write expressions which use operators whose order of evaluation isn't defined, but whose outcome does depend on the order of evaluation. For instance, my previous example could have been written as:
        my $tmp = f(2); print $tmp + f(3);
        and now it doesn't matter which order + has.

        Indeed, if autothreading (in the threads sense rather than the P6 sense (if they are not the same thing?)), is ever going to be possible, it would be necessary to define the order of execution if the outcome of a compound statement is ever going to be predictable.
        So, you need order of execution to do things in parallel, but because there's an order of execution, two things can't happen in parallel?
        A reply falls below the community's threshold of quality. You may see it by logging in.

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://446827]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others chilling in the Monastery: (9)
As of 2024-03-28 09:24 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found