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

[download]
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.

Replies are listed 'Best First'.
Re: !@#$ $#_
by Dominus (Parson) on Mar 25, 2001 at 20:05 UTC
    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.

[reply]

In Section Seekers of Perl Wisdom