Re^3: Sorting, recursion, and tail-call optimizations (why? $i)

Shouldn't incrementing $_[0] effectively increment $i because of the assignment at the top of the block?

Caution: Contents may have been coded under pressure.

Comment on Re^3: Sorting, recursion, and tail-call optimizations (why? $i) Select or Download Code

Replies are listed 'Best First'.
Re^4: Sorting, recursion, and tail-call optimizations (why? $i) by tye (Sage) on Jan 09, 2006 at 14:32 UTC
I was pretty sure the '`my $i`' was "outside the 'loop'" (above the label) when I replied, but I'll assume I just misread that. - tye	[reply] [d/l]
Re^5: Sorting, recursion, and tail-call optimizations (why? $i) by Roy Johnson (Monsignor) on Jan 09, 2006 at 16:32 UTC
Evidently so; I haven't changed that version of `my_sort` in my post. The resulting order is still a mess. However, like the OP, if I use `sort { my_sort() } @data` instead of `sort my_sort @data`, I get correct ordering. So whatever the problem is in using `goto`, it isn't fixed by using `redo`. I begin to smell a bug in perl (or something that could stand to be documented). Printing `$i` each time it is assigned shows that when the sort sub is given by name, its value never decreases. When it is wrapped in a sub, it often goes back to zero. I think the problem is in auto-vivifying `$_[0]`. Caution: Contents may have been coded under pressure.	[reply] [d/l] [select]