Re^3: Why does the first $c evaluate to the incremented value in [$c, $c += $_] ? (alias)

[vsespb]

I understand why aliasing involved when calling function

mysub($c, $c+=1)

But why it's also involved when composing a list?

@a = ($c, $c+=1)

for consistency with function calls? Where is documented?

[tye]

But why [is aliasing] also involved when composing a list?

Most likely because a list can be used like:

( $c, $d ) = ( 1, 2 )

But I'm just guessing. There are usually some subtle implementation details involved. There is often quite complicated history involved as well.

Where is documented?

The types of things that are more likely to change based on changes to Perl having to do with esoteric implementation details, especially optimizations, are often bad things to try to document, IMHO. In any case, I doubt this is documented.

Modifying a variable in the same statement where you use the variable is just something to avoid. Knowing what it does in this version of Perl doesn't mean it will continue to do that in another version of Perl. Having a rough understanding of why it does what it currently does, tends to not be very reliable in allowing even a rather gifted Perl programmer to avoid getting rather different behavior from a very similar construct (and thus being surprised and perhaps resulting in a bug in the code being written).

C is nice in having a standard that pretty clearly lays out this type of thing as officially "undefined behavior". This is a very useful way to push back against clever programers' natural tendency to, from time to time, want to continue to use some overly clever construct.

That C rule and definition don't really apply to Perl. But the motivation for them very much applies to this type of thing in Perl. Trying to tie down exactly how something like this should behave just leads to complex and problematic tying of the hands of the implementers and fixers of bugs in Perl.

So just don't do this type of thing. And don't get too obsessed about why it does what it does. It is more important to understand why it is a construct that you shouldn't be writing. If you've got that down, then you can casually try to better understand what is going on in an attempt to better understand some aspects of Perl. But beware that this might put you at risk of, perhaps unintentionally, relying upon these new assumptions. Best to keep such conclusions you come to marked as guesses or at least vague and not something to rely upon.

[oiskuu]

Read more... (2 kB)

For perl, flexibility in constructing and manipulating lists, e.g. using iterators (with their side effects) and so on, is essential quality of the language. There is no undefined behavior here. This thing quacks like a bug, it is a bug. How much speed-up do you think this buggy optimization is worth?

[tye]

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.