Re: order of arguments evaluated

actually, saying that evaluation is in any fixed order is a bad idea. If you try the same code, but with 3 variables:

sub printit{ print @_; }

my $var = 1;
&printit($var,$var++,$var);
[download]

you will get 212 - would you say now that evaluation starts from the middle?

what happens, I think, is that Perl takes the argument list, and applies any mutators (like ++) in there, before evaluating the rest.

As a general afterthought, having dependent arguments with mutators in a function call, or just in the same statement, sounds like a bad idea. For a start, you might introduce 2 mutators at the same time - which is likely to produce rubbish... how would you expect something like

my $a = NumberObject->new(5);

print SumNumbers($a, $a->square_me(), $a->double_me());
[download]

to behave?

Comment on Re: order of arguments evaluated Select or Download Code

Replies are listed 'Best First'.
Re^2: order of arguments evaluated by BrowserUk (Patriarch) on May 17, 2005 at 06:58 UTC
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.	[reply]
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]
Re^4: order of arguments evaluated by BrowserUk (Patriarch) on May 17, 2005 at 07:38 UTC
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]
Re^5: order of arguments evaluated by kscaldef (Pilgrim) on May 17, 2005 at 18:17 UTC
Re^6: order of arguments evaluated by BrowserUk (Patriarch) on May 17, 2005 at 18:40 UTC
Some notes below your chosen depth have not been shown here
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 `00`. What should that value be? You can devise arguments that it could be either 0 or 1 (i.e. $anything0==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]
Re: 0**0 by Anonymous Monk on May 31, 2005 at 02:45 UTC
Since when is 00 undefined or in question? True, zero times anything is zero, but 00 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]
Re^2: 0**0 by Anonymous Monk on May 31, 2005 at 03:02 UTC
Re^3: 0**0 by gregor42 (Parson) on May 31, 2005 at 18:03 UTC
Some notes below your chosen depth have not been shown here
Re^2: order of arguments evaluated by bsdz (Friar) on May 17, 2005 at 09:42 UTC
Interestingly similar code in Java produces the expected result "112" `public class PrecedenceTest { public PrecedenceTest(){ int i = 1; printIt(i, i++, i); } protected void printIt(int i, int j, int k){ System.out.println( i+"" + j+""+ k+"" ); } public static void main(String[] args){ PrecedenceTest p = new PrecedenceTest(); } }` [download] Thanks to a colleague for writing this :-)	[reply] [d/l]