in reply to Re: order of arguments evaluated
in thread order of arguments evaluated

how would you expect something like ... to behave?

With a defined execution order, this question, the OP's problem and all the previous and future discussions surrounding this subject would be trivial to answer.

Or, more likely, simply would never have arisen.

And the benefits that the Perl coder gets from EO being undefined is?

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?
"Science is about questioning the status quo. Questioning authority".
The "good enough" maybe good enough for the now, and perfection maybe unobtainable, but that should not preclude us from striving for perfection, when time, circumstance or desire allow.

Replies are listed 'Best First'.
Re^3: order of arguments evaluated
by kscaldef (Pilgrim) on May 17, 2005 at 07:10 UTC
    The benefit is that an optimizing compiler can choose to do whatever is fastest.

    And, yes, some people do care about that sort of thing.

[reply]
      The benefit is that an optimizing compiler can choose to do whatever is fastest.

      If I had said C programmers that might be true, but I didn't.

      I assert that there is no situation whereby a Perl programmer will benefit from this (performance wise or otherwise).

      The performance benefit is derivable in C code, because it allows intermediate values of some variables types to be retained in registers longer than might otherwise be the case. This is possible because the value of some of C's intrinsic types fits entirely within a cpu register. None of Perl's intrisic types do.

      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?
      "Science is about questioning the status quo. Questioning authority".
      The "good enough" maybe good enough for the now, and perfection maybe unobtainable, but that should not preclude us from striving for perfection, when time, circumstance or desire allow.
[reply]
[d/l]

        It's certainly possible to benefit from it. For example:

        my $a = 5;
foo(0, $a+1, 2, $a+3);

        [download]

        Can be optimized by a massive reordering of the computation. Two of the subexpressions can be evaluated at compile time!

        More generically, your view of compiler and runtime optimizations is too narrow in my view. It's more than just registers. It's entirely possible that operations might be reordered to improve cache coherency, or for other considerations.

        Updated to remove one objection below: added "my"

[reply]
[d/l]
0**0
by Anonymous Monk on May 31, 2005 at 02:24 UTC
    $i += $i++ - ++$i; Can we agree that that expression is dog ugly? What exactly should the value of $i be after evaluation? Why? Think about 0**0. What should that value be? You can devise arguments that it could be either 0 or 1 (i.e. $anything**0==1 but 0*$anything==0). Assigning meaning to the original expression can be done, but ugly expressions like that should be avoided in the first place. Perl's designers decided that it would be hard to prevent people from writing ugly code, but they're going to wash their hands of the whole enterprise by saying "bah, if you want to shoot yourself in the foot, feel free. Just be aware that we aren't making promises that your program will work properly in the future."
[reply]
[d/l]
[select]
      Since when is 0**0 undefined or in question? True, zero times anything is zero, but 0**0 is the product of zero numbers. Since there are no numbers to multiply, there is no 0 to multiply by anything to apply that rule.

      Multiplying zero numbers together must give the identity for multiplication (that's 1). Just like adding zero numbers together is the identity for addition (that's 0).

      </rant> .. anyway, your point is fine, but bad example ;)

[reply]
        sci.math FAQ: What is 0^0?...
        According to some Calculus textbooks, 0^0 is an ``indeterminate form''. When evaluating a limit of the form 0^0, then you need to know that limits of that form are called ``indeterminate forms'', and that you need to use a special technique such as L'Hopital's rule to evaluate them. Otherwise, 0^0 = 1 seems to be the most useful choice for 0^0. This convention allows us to extend definitions in different areas of mathematics that otherwise would require treating 0 as a special case. Notice that 0^0 is a discontinuity of the function x^y. More importantly, keep in mind that the value of a function and its limit need not be the same thing, and functions need not be continous, if that serves a purpose (see Dirac's delta). This means that depending on the context where 0^0 occurs, you might wish to substitute it with 1, indeterminate or undefined/nonexistent...
[reply]

In Section Seekers of Perl Wisdom