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]

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?

That is not an optimisation.

Who said anything about optimisation?

It would also prevent the bug from manifesting itself.

What bug?

If the sequences were:

Sure, but that's not what the OP wrote.

Or are you suggesting that making a copy of the non-last operand of every operator is somehow a good idea?

Reguarding the update, I believe you're suggesting it would be more efficient to implement

$a.$b.$c.$d
[download]

as

concat_assign(  
   concat_assign( 
      concat_assign( copy($a), $b ),
      $c,
   ),
   $d
)
[download]

rather than how it's actually implemented. However, I believe it's being implemented as the following, which is practically the same (ever so slightly better):

concat_assign(  
   concat_assign( 
      concat( $a, $b ),
      $c,
   ),
   $d
)
[download]

I believe that's what's causing the "S" to appear in concat's flags.

$ perl -MO=Concise,-exec -e'$a.$b.$c.$d'
1  <0> enter 
2  <;> nextstate(main 1 -e:1) v:{
3  <#> gvsv[*a] s
4  <#> gvsv[*b] s
5  <2> concat[t3] sK/2
6  <#> gvsv[*c] s
7  <2> concat[t5] sKS/2
8  <#> gvsv[*d] s
9  <2> concat[t7] vKS/2
a  <@> leave[1 ref] vKP/REFC
-e syntax OK
[download]

But the problem with both of the approaches is that enlarging the string buffer requires copying it (at least on this Debian machine), so the "buk" and current version is usually more expensive (6 bytes rather than 3) than the naïve one I had posted.

A string buffer is only given 4 extra bytes when it's grown, which is pityful. (In comparison, arrays are given N+4 extra elements!) Aside from adding more padding, one could convert concat into an N-ary operator rather than a binary operator.

sub concat_list :lvalue {
   my $tot_len;
   $tot_len += length($_) for @_;
   my $buf = '';  # Allocate $tot_len bytes.
   $buf .= $_ for @_;
   $buf
}
[download]

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.

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?

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.