Re^4: Order of evaluation/interpolation of references

[BrowserUk]

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.

[LanX]

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)}";

OUTPUT:

X
Y
22
X
Y
1 2

[BrowserUk]

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

which behavior is wrong and which is right?

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

[LanX]

> 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

X
Y
22
X
Y
2 2
X
Y
1 2

[Jenda]

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!