Re: Re: !@#$ $#_

[MeowChow]

in reply to Re: !@#$ $#_
in thread !@#$ $#_

Yeppers, I suppose the following snippet fully illustrates the issue, without employing side-effect operators:

my $i = 0;
sub foo { $i = $i + 1 }

print ($i, ${\$i}, foo(), $i + 0, foo(), foo(), foo(), $i);
### prints: 44112344

It looks as if any complex sub-expressions /subroutine calls are evaluated in order, and variables/references are evaluated last.

Seems rather un-perlish, but at least subroutine calls are done in-order.

[Dominus]

Says MeowChow:

It looks as if any complex sub-expressions /subroutine calls are evaluated in order, and variables/references are evaluated last.

That's very astute of you. It's not exactly what's going on, but it's very close. For simple variables, Perl pushes what is effectively a reference onto the stack. But for complex ecpressions, Perl must construct the new value and push a reference to that instead. So if $i = 2, then $i in the list pushes a reference to $i itself, but $i + 0 copies $i and pushes a reference to the copy of the 2. If you later change $i, the first 2 changes but the second one doesn't.

Your original example works the same way.

This could be considered a bug. It has come up on p5p before, but I don't remember what the outcome of the discussion was.

Contrary to what chromatic said, it is not a precedence issue. Precedence only affects parsing, not execution.