Re: !@#$ $#_

[chromatic]

There's a thread on p5p that has to do with Precedence. Just like in C, the order of evaluation is not strictly determined.

The original thread starts here, where our own japhy says "It hurts when I stick a fork in my eye!"

Seriously, it's a combination of recursion and modifying a global (@_). If you copy the arguments into a lexical array in li(), you'll get better results.

Update: chromatic resolves to be more specific about his terminology.

[MeowChow]

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.