Re: Order of evaluation/interpolation of references

[JavaFan]

So, you're doing ++ multiple times on the same variable in the same statement, and you're getting results that you don't expect.

Time to whip out the manual!

Note that just as in C, Perl doesn't define when the variable is incremented or decremented. You just know it will be done sometime before or after the value is returned. This also means that modifying a variable twice in the same statement will lead to undefined behaviour. Avoid statements like:

$i = $i ++;
print ++ $i + $i ++;

Perl will not guarantee what the result of the above statements is.

You're doing just that. You do something that is documented to not guarantee what the result is.

It's fine if you go that way. Just don't ask why you're getting the results you're getting.

[BrowserUk]

you're doing ++ multiple times on the same variable in the same statement

If that's true, and I'm not totally convinced it is, but neither can I prove otherwise, then it is a poster child for the stupidity of whole "undefined behaviour" meme.

It effectively means that you can never call two functions in the same statement. At least without not having looked deep into the guts of them.

And that just makes a mockery of encapsulation, modularisation, libraries ...

Even worse as someone (was it you?) recently showed that deciding exactly what constitutes "as statement" in Perl is far from trivial.

[tye]

Not really. X() does not look the same as ${X()}. Having a function that returns a reference to a scalar is something unusual and that can't even be made to look "vanilla" in the calling code.

Returning the same reference to the same scalar but (hopefully) having different values each time is fundamentally a broken design.

Perl mostly makes copies of things but there are no shortage of places where Perl keeps aliases to things. So, Perl making a copy soon enough can save one from such a broken design in a lot of cases. Such may even convince one that the design is not so horrible. But it isn't hard to come up with ways to use such a broken thing where the copying doesn't happen fast enough.

One could certainly prefer a language where copying is always done. That certainly has merits.

And this is certainly not just an "undefined order of operations" problem. But, yes, exactly when the copying happens is a subtle interplay of a bunch of things, many of which are subject to optimization and/or the result of previous optimizations.

Trying to exactly specify the precise order of such subtle "operations" looks like a fool's errand to me (I don't think anybody would ever succeed). Doing so would also certainly prevent the possibility of most optimizations.

Note that the important "operation" here is the copying of a scalar which is not even an operation explicitly called out in the code. It is a implementation detail of string concatenation (which is also not explicitly coded).

Not that I expect you to agree with any of that. I didn't reply for your benefit.

[BrowserUk]

If it was because the calls (or dereferences; or pre/post increments to the same variable) were "in the same statement", this wouldn't happen:

C:\test>perl -e"{my$x=0; sub X{++$x;\$x}} print qq[${X()}${X()}${X()}\
+n]"
223

C:\test>perl -e"{my$x=0; sub X{++$x;\$x}} print qq[${X()} ${X()}${X()}
+\n]"
1 23

Doing so would also certainly prevent the possibility of most optimizations.

Besides that you cannot back that up with any proof, the golden rule of optimisations is that they don't break code that isn't broken without them.

Undefined ordering makes some sense in C, where the re-ordering of operations can have a significant impact upon performance.

In perl, it makes no sense at all.

[JavaFan]

Here's a variation that doesn't use ++, and shows the same behaviour:

use 5.010;
my $x;

sub X {
    $x = shift;
   \$x;
}

say "${X(1)}${X(2)}";
say "${X(1)} ${X(2)}";
__END__
22
1 2

[chromatic]

If you use B::Concise and compare the optrees, the second form has two concat ops where the former only has one. Given the work the core goes through to manage the lifespans of SVs put on the Perl stack, I find this bug-like behavior unsurprising.

[BrowserUk]

Which actually supports my premise rather than denies it.

It says that this is "a single statement":say "${X(1)}${X(2)}";

And this isn't:say "${X(1)} ${X(2)}";

Which, by digging deep into the guts of how Perl parses the statements may be demonstrably true, but to expect users to know that is a joke.

And even if the 'optimisation' did shave a few cycles, that it produces the wrong result, surely makes it a archetypically premature.