|
Re^2: Order of evaluation/interpolation of references
by BrowserUk (Patriarch) on Mar 07, 2012 at 21:38 UTC
|
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.
With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
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".
| [reply] |
|
|
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.
| [reply] |
|
|
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.
With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
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".
| [reply]
[d/l] |
|
|
|
|
|
|
|
|
|
|
|
|
|
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
| [reply]
[d/l]
[select] |
|
|
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.
| [reply]
[d/l] |
|
|
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.
With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
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".
| [reply]
[d/l]
[select] |
|
|
|
|
|