Re^5: Sorting, recursion, and tail-call optimizations

I wonder if this might have something to do with it...

If the subroutine's prototype is "($$)", the elements to be
compared are passed by reference in @_, as for a normal subrou-
tine.  This is slower than unprototyped subroutines, where the
elements to be compared are passed into the subroutine as the
package global variables $a and $b (see example below).

Maybe a prototype is being applied to the "borked" sub call?

Comment on Re^5: Sorting, recursion, and tail-call optimizations

Replies are listed 'Best First'.
Re^6: Sorting, recursion, and tail-call optimizations by Limbic~Region (Chancellor) on Jan 06, 2006 at 18:34 UTC
kwaping, You can see in the code that I am not using any prototypes. Additionally, it would be really wacky if when sort called it the first time it didn't see it as a prototyped sub (used $a and $b) but when it got recursed the first time it did (using references in @_). I know this is not the case because I printed the values of @_ and they are correct. It is the undefined $a and $b and the mysterious blowing up that has me baffled. Cheers - L~R	[reply]
Re^7: Sorting, recursion, and tail-call optimizations by kwaping (Priest) on Jan 06, 2006 at 18:36 UTC
I know you're not implicitly prototyping the sub, just wondering if maybe there was some mysterious under-the-hood process that was applying one. But then, I (obviously?) have no idea about any of what I've posted in this thread. :)	[reply]