Beefy Boxes and Bandwidth Generously Provided by pair Networks
Perl Monk, Perl Meditation
 
PerlMonks  

Re^2: Pre vs Post Incrementing variables

by ikegami (Patriarch)
on Sep 12, 2010 at 16:12 UTC ( [id://859868]=note: print w/replies, xml ) Need Help??


in reply to Re: Pre vs Post Incrementing variables
in thread Pre vs Post Incrementing variables

It's got nothing to do with operand evaluation order. It has to do with pre-increment returning lvalues.

f(++$i, ++$i)
is more or less equivalent to
do { local @_; alias $_[0] = ++$i; alias $_[1] = ++$i; &f; }

Since the pre-increment operator returns the variable itself and not a copy, the above is the equivalent to

do { local @_; ++$i; alias $_[0] = $i; ++$i; alias $_[1] = $i; &f; }

As you see, f() sees the same value for both arguments as both arguments are the same variable.

Replies are listed 'Best First'.
Re^3: Pre vs Post Incrementing variables
by BrowserUk (Patriarch) on Sep 12, 2010 at 17:41 UTC
    It's got nothing to do with operand evaluation order.

    Who said anything about operand evaluation order? (How could there be an operand evaluation order for a unary operator.)

    I'll come back to this.

    It has to do with pre-increment returning lvalues.
    $i = 0; ++$i = 'fred';; Can't modify preincrement (++) in scalar assignment

    So, not an lvalue.

    is more or less equivalent to ... alias

    Ah! That well know Perl keyword 'alias'....

    It's got nothing to do with operand evaluation order.

    Hm. "It" has everything to do with the fact that the evaluation order of sub-expressions is unspecified.

    Where "it" is the contradictory and useless behaviour, observed by the OP, and repeated in my post.

    Because, if were specified, then the implementation would not be able to get away with producing those totally illogical, useless results, for those unwise or unknowing enough to try and use, what could be a useful behaviour.

    Your attempts to explain how the implementation produces these useless results from this unspecified and therefore deprecated code, does naught to detract from the reason why it has been possible to enshrine this broken behaviour in the implementation.

    The fact that f( ++$n, ++$n ) passes an alias to $n, rather than the value resulting from the preincrement, is just another broken behaviour. It is equivalent to C allowing:

    #include <stdio.h> void f( int *a, int *b ) { printf( "a: %d, b: %d \n", *a, *b ); *a = 1; *b = 2; } int main( int argc, char ** argv ) { int x = 0; f( &( ++x ), &( ++x ) ); return 0; }

    Which it doesn't:

    junk.c junk.c(11) : error C2102: '&' requires l-value junk.c(11) : error C2102: '&' requires l-value junk.c(11) : error C2198: 'f' : too few arguments for call

    Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
    "Science is about questioning the status quo. Questioning authority".
    In the absence of evidence, opinion is indistinguishable from prejudice.
        $i = 0; ++$i = 'fred';; Can't modify preincrement (++) in scalar assignment

        So, not an lvalue.

      Hmm. I was looking at this prior to my previous post. Notice that:
      do { my $i = 16; ${ \(++$i) } = 'fred'; $i }; # returns 'fred' do { my $i = 16; ${ \($i++) } = 'fred'; $i }; # returns 17

      Maybe the warning you got is due to how Perl parses the preincrement assignment expression? I don't know.

        Waddayaknow! And I've even found a use for it:

        print map ${ \( ++$i ) } %= 10, 1..30;; 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0

        Now all we've gotta do is document it, and we've a valid reason for it working that way: measuring golf games. Perfect :)


        Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
        "Science is about questioning the status quo. Questioning authority".
        In the absence of evidence, opinion is indistinguishable from prejudice.

        Mind you, it might make explaining this one a tad awkward :)

        $i = 0; print ++${\++$i}, 0+ ++$i, 0+ ++$i, ++${\++$i};; 6 3 4 6

        Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
        "Science is about questioning the status quo. Questioning authority".
        In the absence of evidence, opinion is indistinguishable from prejudice.

      Who said anything about operand evaluation order? (How could there be an operand evaluation order for a unary operator.)

      You did, or rather the passage you quoted. The expressions whose order of evaluation is not defined are those that are operands. The order of those that aren't operands — those that are statements — is well defined.

      No, the list operator is not a unary operator.

      So, not an lvalue.

      It appears that Perl doesn't realise that ++$i returns an lvalue (thus the syntax error), but it does.

      $ perl -E'sub { $_[0]="fred"; }->($i++); say $i' 1 $ perl -E'sub { $_[0]="fred"; }->(++$i); say $i' fred

      Ah! That well know Perl keyword 'alias'....

      You understood what that code did, right? Troll. It's actually an imported function, fyi.

      "It" has everything to do with the fact that the evaluation order of sub-expressions is unspecified.

      No, even if "it" was specified — it's currently left to right for all the operators involved — the results would be the same.

      The fact that f( ++$n, ++$n ) passes an alias to $n, rather than the value resulting from the preincrement, is just another broken behaviour.

      That's entirely possible.

      It is equivalent to C allowing:

      Perl passes args by reference and C can't, so I don't see your point. It is equivalent to C++ allowing:

      #include <stdio.h> void f( int &a, int &b ) { printf( "a: %d, b: %d \n", a, b ); a = 3; b = 4; } int main( int argc, char ** argv ) { int x = 0; f( ++x, ++x ); printf( "x: %d \n", x ); return 0; }

      Which it does:

      $ g++ -o a a.cpp && a a: 2, b: 2 x: 4
        You did, or rather the passage you quoted. The expressions whose order of evaluation is not defined are those that are operands.

        Okay. I see where you are coming from. You think that you know better what the authors of that passage meant when they wrote it, than they did. "They" being Kernighan & Ritchie in "Appendix A:The C reference Manual" of "The C Programming Language".

        That explains a great deal.


        Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
        "Science is about questioning the status quo. Questioning authority".
        In the absence of evidence, opinion is indistinguishable from prejudice.
      The fact that f( ++$n, ++$n ) passes an alias to $n, rather than the value resulting from the preincrement, is just another broken behaviour.
      Note that this behaviour isn't unique to ++.
      sub f {say "@_"} my $n = 1; f $n += 2, $n += 2; __END__ 5 5
        grep, values and lvalue subs also return lvalues. substr, pos and keys can also return lvalues.

Log In?
Username:
Password:

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

How do I use this?Last hourOther CB clients
Other Users?
Others learning in the Monastery: (6)
As of 2024-04-21 15:31 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found