Re^3: Order of evaluation/interpolation of references (op order)

Replies are listed 'Best First'.
Re^4: Order of evaluation/interpolation of references (op order) by BrowserUk (Patriarch) on Mar 07, 2012 at 22:31 UTC
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` [download] 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". In the absence of evidence, opinion is indistinguishable from prejudice. The start of some sanity?	[reply] [d/l]
Re^5: Order of evaluation/interpolation of references (op order) by ikegami (Patriarch) on Mar 08, 2012 at 01:26 UTC
In perl, it makes no sense at all. Operand evaluation order is actually well defined and system-independent even though it's not documented for most operator. Operands are evaluated as late as possible, left-to-right except for assignment operators which are right-to-left. (Exponentiation's operand evaluation order is left-to-right, so its operand evaluation order differs from its operator associativity.) `${ X() } . ${ X() } concat( deref( X() ), deref( X() ), ) ${ X() } . ' ' . ${ X() } concat( concat( deref( X() ), ' ', ), deref( X() ), )` [download] The key here is that `${ X() }` returns `$x` itself, not a copy of it. `use strict; use warnings; use feature qw( say ); {my$x=0; sub X{++$x;\$x}} sub concat { $_[0] . $_[1] } sub deref :lvalue { ${ $_[0] } } # 22 say concat( deref( X() ), deref( X() ), ); # 3 4 say concat( concat( deref( X() ), ' ', ), deref( X() ), );` [download]	[reply] [d/l] [select]
Re^6: Order of evaluation/interpolation of references (UPDATED) by BrowserUk (Patriarch) on Mar 08, 2012 at 02:16 UTC
The problem with this pseudo-code: `${ X() } . ${ X() } concat( deref( X() ), deref( X() ), )` [download] is that it means that concat() copies both it arguments -- rather than a copy of the second being appended to the first -- otherwise it would modified the referenced var. Which means that here: `${ X() } . ' ' . ${ X() } concat( concat( deref( X() ), ' ', ), deref( X() ), )` [download] The deref'd value and the space are copied once to put them together, and then the whole thing is copied again in the second concat(). That is not an optimisation. If the sequences were: `${ X() } . ${ X() } concat( new( deref( X() ) ), deref( X() ), )` [download] `${ X() } . ' ' . ${ X() } concat( concat( new( deref( X() ) ), ' ', ), deref( X() ), )` [download] Ie. concat() appends it second argument to its first (as in sv_catsv()) and new() return a copy of its argument (as in newSVsv()), the each part of the final string is only copied once (subject to the need for reallocs which will be unnecessary for two or three short strings because of allocation (alignment) minimums), and it would be more efficient. It would also prevent the bug from manifesting itself. Update: Maybe this will clarify things; or not: use strict; use warnings; use feature qw( say ); package ike; { sub concat { $_[0] . $_[1] } sub deref :lvalue { ${ $_[0] } } my $a = \ '1'; my $b = \ '2'; say concat( deref( $a ), deref( $b ), ); say $$a; say <<'EOS'; Note: $$a has not changed, So, $$a was copied to produce the concatena +tion 1 + 1 = 2 bytes copied. EOS say concat( concat( deref( $a ), ' ', ), deref( $b ), ); say <<'EOS'; Note: $$a has not changed, So, $$a was copied to produce the concatena +tion Therefore, the whole of that result was copied (again) to produce the result of the second concatenation. ( 1 + 1 ) * 2 + 1 = 5 bytes copied. EOS } package buk; { sub concat { $_[0] .= $_[1] } sub deref { ${ $_[0] } } sub new{ "$_[0]" } my $a = \ '1'; my $b = \ '2'; say concat( concat( new( deref( $a ) ), ' ', ), deref( $b ), ); say <<'EOS'; New copies 1 byte its arg into a new string The first concat() copes the space and apend it to the new string. The second concat() copies 1 byte from $b and apend it to that. 1 + 1 + 1 = 3 bytes copied. EOS } __END__ C:\test>junk999 12 1 Note: $$a has not changed, So, $$a was copied to produce the concatena +tion 1 + 1 = 2 bytes copied. 1 2 Note: $$a has not changed, So, $$a was copied to produce the concatena +tion Therefore, the whole of that result was copied (again) to produce the result of the second concatenation. ( 1 + 1 ) * 2 + 1 = 5 bytes copied. 1 2 New copies 1 byte its arg into a new string The first concat() copes the space and apend it to the new string. The second concat() copies 1 byte from $b and apend it to that. 1 + 1 + 1 = 3 bytes copied. [download] 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". In the absence of evidence, opinion is indistinguishable from prejudice. The start of some sanity?	[reply] [d/l] [select]
Re^7: Order of evaluation/interpolation of references (op order) by ikegami (Patriarch) on Mar 08, 2012 at 02:35 UTC
Re^8: Order of evaluation/interpolation of references (op order) by BrowserUk (Patriarch) on Mar 08, 2012 at 02:41 UTC
Some notes below your chosen depth have not been shown here
Re: Optimising concat (was Order of evaluation/interpolation of references) by ikegami (Patriarch) on Mar 09, 2012 at 02:29 UTC
Re^2: Optimising concat (was Order of evaluation/interpolation of references) by BrowserUk (Patriarch) on Mar 09, 2012 at 02:46 UTC
Some notes below your chosen depth have not been shown here
Re^5: Order of evaluation/interpolation of references (quirks) by tye (Sage) on Mar 08, 2012 at 00:01 UTC
If it was because the calls [...] were "in the same statement", this wouldn't happen: Note that I never said "in the same statement". That surely came from something specific from the C spec. It can be somewhat and roughly applied to Perl in a lot of ways, but in a lot of ways it does not apply. A lot of people reach for that because it was one of the better known and clearer expressions of the more general concept of "it is foolish to rely upon subtle quirks in a specific implementation" and because many of the examples of this in perl (like `print ++$x,'.',$x++`) look very much like things that are clearly declared "undefined" in standard C. Some people push pretty strongly for this mis-application of that part of the C standard to Perl. Some of that is surely motivated by a desire to push back against the naive but powerful urge to declare "same $code acts different" as unambiguously implying "that is a bug" (whether "different" means in different builds of Perl or in different looping constructs or whatever). Heck, you just nearly jumped to the "if an optimization can change anything, than the optimization is buggy" conclusion yourself. But it will always be possible to do particularly stupid things in Perl code such that the outcome of said thing will be subject to (that is, will be changed by) subtle decisions deep in some obscure part of the Perl interpreter. But it is also quite easy to avoid doing such stupid things. But that requires that one acknowledge that some things are stupid because they are particularly risky to being impacted by unintended side effects of optimizations, bug fixes, and feature enhancements. This was made quite explicit, authoritative, and precise in the C standard, so people often reach for it, even though it is an imperfect fit here at best. If your code breaks when the Perl expression `$x.$y` is noticed to be inefficient because it does "stringify $x (into a copy), stringify $y (into a copy), concat the two (into a third copy)", then I'm pretty sure you've done something stupid in your Perl code. But the exact details of how `$x.$y` gets accomplished might change because it was found that certain cases produce less than desirable results. So if some subtle detail has unfortunate side effects on non-stupid Perl code, then the maintainers of the Perl interpreter certainly might improve those results at the expense of possibly causing code that stupidly relied on those unfortunate results being broken by the change. Unfortunately, sometimes subtle happens. But I believe that is inevitable. - tye	[reply] [d/l] [select]
Re^6: Order of evaluation/interpolation of references (quirks) by BrowserUk (Patriarch) on Mar 08, 2012 at 00:46 UTC
Note that I never said "in the same statement". No, I did in the post to which you replied, quoting from the post to which I responded. If your code breaks when the Perl expression $x.$y is noticed to be inefficient because it does "stringify $x (into a copy), stringify $y (into a copy), concat the two (into a third copy)", then I'm pretty sure you've done something stupid in your Perl code. Hm. Stupid is not illegal. And if it's not illegal, it shouldn't break. Requiring users to know that `"${x()}${X()}"` is equivalent to `$r1 = X(), $r2 = X(), "$$r1$$r2"` is expecting an awful lot. 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". In the absence of evidence, opinion is indistinguishable from prejudice. The start of some sanity?	[reply] [d/l] [select]
Re^5: Order of evaluation/interpolation of references (op order) by AnomalousMonk (Archbishop) on Mar 07, 2012 at 23:05 UTC
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` [download] `C:\test>perl -e"{my$x=0; sub X{++$x;\$x}} print qq[${X()} ${X()}${X()} +\n]" 1 23` [download] But as I understand what's going on, 'this' must happen within a single statement given the clearly defined precedence (in particular, the left-associativity) of the concatenation operator and the particular state-saving behavior of the `X()` function in question (note that no pre/post-in/decrement operators were harmed in the following example): >perl -wMstrict -le "{ my $x = 0; sub X () { $x = $x + 1; return \$x; } } ;; print ${X()}; print ${X()} . ${X()}; ;; print ${X;} . ${X;} . ${X;}; print ${X;} . 'x' . ${X;} . ${X;}; " 1 33 556 7x89 >perl -wMstrict -MO=Deparse,-p,-q -le "{ my $x = 0; sub X () { $x = $x + 1; return \$x; } } ;; print ${X()}; print ${X()} . ${X()}; ;; print ${X;} . ${X;} . ${X;}; print ${X;} . 'x' . ${X;} . ${X;}; " BEGIN { $^W = 1; } BEGIN { $/ = "\n"; $\ = "\n"; } use strict 'refs'; { (my $x = 0); sub X () { ($x = ($x + 1)); return((\$x)); } ; } print(${X;}); print((${X;} . ${X;})); print(((${X;} . ${X;}) . ${X;})); print((((${X;} . 'x') . ${X;}) . ${X;})); -e syntax OK [download] And yes, I must agree with tye that it's not the sort of code I would wish upon anyone I liked, but it does seem to make sense.	[reply] [d/l] [select]