Beefy Boxes and Bandwidth Generously Provided by pair Networks
laziness, impatience, and hubris
 
PerlMonks  

Re^6: Why does the first $c evaluate to the incremented value ... (hahaha)

by tye (Sage)
on Mar 05, 2014 at 20:09 UTC ( #1077148=note: print w/replies, xml ) Need Help??


in reply to Re^5: Why does the first $c evaluate to the incremented value ... (bug)
in thread Why does the first $c evaluate to the incremented value in [$c, $c += $_] ?

Perl does indeed value giving the programmer flexibility in how to write things. That means you are allowed to write things stupidly. When you do, you suffer.

How much speed-up do you think this buggy optimization is worth?

Who declared that this was due to an optimization? It is as likely to be due to a simplification. If you think tying the hands of the implementers is a trivial concern, then you should probably go try to be an implementer of Perl's C code at this point. Go fix this "bug" in the Perl source code. If you don't succeed, at least you might get a much better appreciation for the trade-offs involved in trying to make stupid constructs behave predictably (in the eyes of their too-clever authors).

As to your "lawyer mode", you have jumped to conclusions about how precisely the "don't modify something twice in the same expression" taboo is the same in Perl as in C. Note that I didn't admonish you to not modify something twice in the same expression. Also note that I didn't say anything about "sequence points". I said you should not use a variable in the same statement where you have modified it.

Perl has aliases and whether you get an alias or a copy can be subject to rather subtle factors, arcane implementation details, and (indeed) optimizations. C doesn't have this feature and so C rules don't address it. So simple order of operations is not the only gotcha when writing Perl code. And yet, I don't find it difficult at all to avoid separately using something in the same statement where I've modified it.

I don't really know how much slower the average Perl code would run if a whole class of uses of a bare variable where forced to make a copy of the variable's value just in case somebody got way too clever and decided to modify the variable in that same statement. It might be a bigger performance hit than you seem to expect.

But even if you went and implemented that, you'd likely just get burned later by complaints about how you "broke" some other clever code that was relying on the fact that the value was changing because it wasn't a copy.

Working on Perl's C code is complex enough already. We don't need to make it that much worse via misguided attempts to "define" the behavior of stupidly ambiguous constructs.

- tye        

  • Comment on Re^6: Why does the first $c evaluate to the incremented value ... (hahaha)

Replies are listed 'Best First'.
Re^7: Why does the first $c evaluate to the incremented value ... (hahaha)
by oiskuu (Hermit) on Mar 05, 2014 at 21:00 UTC

    My "lawyer mode" rant was to show that C is playing catch-up in some areas, and that the rules are anything but clear-cut.

    I wouldn't consider perl code that the OP wrote, stupid. In fact I might quite possibly have used the same construct...

      Then you simply need to update your best practices to include "Using a variable in the same statement as you separately modify it is stupid".

      (Then, when it breaks [as it did] you'll save a lot of time by not trying to convince people that it is a bug. :)

      - tye        

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://1077148]
help
Chatterbox?
and all is quiet...

How do I use this? | Other CB clients
Other Users?
Others making s'mores by the fire in the courtyard of the Monastery: (3)
As of 2018-08-16 02:44 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?
    Asked to put a square peg in a round hole, I would:









    Results (166 votes). Check out past polls.

    Notices?