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

What if f(), g() and h() get their values from arrays (or external sources) in lockstep? Ie. each call returns the next value from it's respective source.

The compiler arbitrarially opts to not call some of those functions when one of them returns 0, all subsequent calculations are wrong because the sequences are no longer in step. Is 0 a second class number?

So now the only way to avoid the compiler subverting what the programmer know he needs is for the programmer to play hostage to the compiler and code: 

my $temp1 = f(a);
my $temp2 = g(b);
my $temp3 = h(c);
my $result = ($temp1 + $temp2) * $temp3;

[download]

You call that an optimisation? That is so ludicrous as to be laughable, except it is where thing stand right now--and, on the basis of majority opinion in this thread, the way it is likely to be in the future. No that is laughable!

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

Replies are listed 'Best First'.
Re^34: Side-effects are bad form [was: Why is the execution order...]
by Anonymous Monk on Apr 19, 2005 at 14:55 UTC
    So now the only way to avoid the compiler subverting what the programmer know he needs is for the programmer to play hostage to the compiler and code
    Well, either that or avoid side-effects in your functions. Is that really so much to ask? You do realize you should try to minimize the use of side-effects in general, right? Just like you should limit your use of global variables and gotos?
[reply]
      Assignment is a side-effect. And it's hard to write a useful Perl program that doesn't do assignment.
[reply]
        Yeah, but you can keep the effects *local* and not spread out all over the place like BrowserUk seems to be worried about.
[reply]

      Any form of IO is a side-effect, regardless of where you do it.

      In an imperative language, 'functions' (procdures that return values if you prefer) are the major mechanism of code structuring. When I do IO to a database, I call a function (or method (same difference). When I read or write to a file, I call a function. When I read or write to a socket udp/tcp/http/ftp/telnet/et al, it is all done with functions and all of those functions that do IO have side-effects. f(a) + g(b) * h(c)

      f(a) retrieves the range from the radar.

      g(b) retrieves a correction factor from the wind speed indicator.

      h(c) gets a scalar from a lookup table in memory. keyed upon the type of shell (HE, tracer, AP) that will load next from the belt.

      The final result is used to adjust the elevation of the barrel in real time.

      How do you avoid the side effects?

      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]
        OK, for all pedants out there, here's a slight modification:
        Avoid side-effects if at all possible. If you absolutely have to use them, make sure you try as hard as you can to have them act in as limited scope as possible.
        Your example is perfect. Why in the world should f interact or depend on g or h? They shouldn't! It is a sign of poor programming if they did. BTW, I (heart) Perl, but God help any unfortunate soul who's life would depend on the correct functioning of a Perl program.
[reply]
[d/l]
[select]
        Trivial. 

        my $f = f(a);
my $g = g(b);
my $h = h(c);
$f + $g * $h;

        [download]
        And then you fire the programmer putting such side-effects in the code.
[reply]
[d/l]
        A reply falls below the community's threshold of quality. You may see it by logging in.
Re^34: Why is the execution order of subexpressions undefined? (magic ruts)
by Anonymous Monk on Apr 19, 2005 at 13:31 UTC
    Replace + with ||, and * with &&.

    Still ludicrous?

[reply]

      No. Logical operators short circuit, but you do not do associative and communicative math with logical operators.

      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]
        That's not my point. My point is that there are already operators where EXPR1 OP EXPR2 may cause one of the expression to not be evaluation, and people don't find that strange. Or inconvenient.

        And in languages with lazy evaluation, this is common.

[reply]

In Section Seekers of Perl Wisdom