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]

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

I'm not upset. I just don't think it can be explained away as coder error.

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

Perl is not one of those languages.

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?

Because the string is huge and you want to avoid copying it twice.

Nobody thinks twice about returning a reference to an array or hash to avoid unnecessary copying:

C:\test>perl -E"{my@x; sub X{ push@x,'some interesting value';;\@x}}; 
+say qq[@{X()}@{X()}]"
some interesting valuesome interesting value some interesting value
[download]

which behavior is wrong and which is right?

NB: there are 3 interesting values above, not four. Is that debatable?

---

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?

> Perl is not one of those languages.

Granting the freedom to use lethal weapons, doesn't mean that you should scratch your ears with a loaded gun.

> Because the string is huge and you want to avoid copying it twice.

The string is huge and manipulated twice in the same statement???

And are you sure that the temporary string created while dereferencing is cheaper then returning a copy?

> NB: there are 3 interesting values above, not four. Is that debatable?

ok in the meantime I updated the post you replied to, as you can see there this behavior is logical.

first call to X() returns 1 interesting value second call to X() returns 2 interesting values.

The problem is that string interpolation in Perl has a backdoor to allow evaluation of code in dereferencing context ... but the exact timing is not obvious!

 qq[@{X()}@{X()}]

This is effectively a poor man's templating system in many senses, especially because it's too poor to be predictable.

Without that backdoor, you'd be forced to use printf or explicit concats and this whole "problem" doesn't exist anymore.

So the only thing proven is that misusing interpolation to eval code with side-effects is a very bad idea!

use 5.010;
{
  my $x;
 
  sub X {
    say "X";
    $x = shift;
    \$x;
  }
 
  sub Y {
    say "Y";
    $x = shift;
    \$x;
  }
}
 
printf "%s%s\n",${X(1)},${Y(2)};
printf "%s %s\n",${X(1)},${Y(2)};
print ${X(1)}." ".${Y(2)};                 # updated
[download]

X
Y
22
X
Y
2 2
X
Y
1 2
[download]

Cheers Rolf

What was it they said about premature optimization?

The thing that's debatable about the array example is whether anything like that should ever appear anywhere other than an obfu competition. Though ... debatable ... debatable it ain't. It should not!

Jenda
Enoch was right!
Enjoy the last years of Rome.