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.

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?

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]

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        

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.

use 5.010;
my $x;

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

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

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.

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".

In the absence of evidence, opinion is indistinguishable from prejudice.

The start of some sanity?

I don't understand why you are so upset about this behavior.

There are good reasons why some languages work hard on being side-effect free.

X() has side-effects causing problems and I have problems imagining any practical application of this pattern.

Or could you show me a reason to return the reference of the same static closure variable instead of the value itself?

>that it produces the wrong result,

sorry but which behavior is wrong and which is right? That's highly debatable.

UPDATE:

As you can see from the following code, Y() is always executed after X(), the problem is only in the timing of variable interpolation.

and this only in conjunction of the highly disputable trick, to inject code execution by dereferencing. (IMHO allowing this is a design weakness)

use 5.010;
{
  my $x;
 
  sub X {
    say "X";
    $x = shift;
    \$x;
  }
 
  sub Y {
    say "Y";
    $x = shift;
    \$x;
  }
}
 
say "${X(1)}${Y(2)}";
say "${X(1)} ${Y(2)}";
[download]

OUTPUT:

X
Y
22
X
Y
1 2
[download]

Cheers Rolf