in reply to Re^6: Sorting, recursion, and tail-call optimizations
in thread Sorting, recursion, and tail-call optimizations

You miss my point. I'm not talking about $a & $b.

When the comparator is first called, if no parameters are passed, then @_ should be empty and $_[0] is "undefined". That's not undefined, but undefined in the non-useful, undefinable, implementation dependant, DO NOT USE sense.

$_[0] obviously is pointing (aliasing) somewhere, but where?

My best guess is that @_ contains the contents of the previous stack frame. Ie. the contents of @_ when the comparator is called, are the same as those passed to the function that is calling the comparator. which would be sort.

In which case, you are probably incrementing the address of the comparator itself--which would at least explain why it blows up!

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal?
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.
  • Comment on Re^7: Sorting, recursion, and tail-call optimizations

Replies are listed 'Best First'.
Re^8: Sorting, recursion, and tail-call optimizations
by Limbic~Region (Chancellor) on Jan 06, 2006 at 18:45 UTC
    BrowserUk,
    You miss my point. I'm not talking about $a & $b.

    I know, but that is where I can actually see a problem, not with @_.

    When the comparator is first called, if no parameters are passed, then @_ should be empty and $_[0] is "undefined".

    Yep, spot on. I auto-vivify $_[0] the first time it is called (which works great).

    In which case, you are probably incrementing the address of the comparator itself

    I am only vaguely getting at what you are trying to say here. The value of $_[0] is correctly being auto-vivified, incremented, and preserved between calls. I would think if it were the address of the comparator itself getting incremented then the second call wouldn't be possible.

    I am not saying you are wrong because I definately respect your knowledge. I am just saying that nothing in any of my tests lead me to believe something is a miss with @_. The only thing that isn't behaving correctly is $a and $b. Even if it was with @_ - I still don't see how sort routine @list and sort { routine() } @list would make that much of a difference.

    Cheers - L~R

[reply]
[d/l]
[select]

      Autovivifying values into @_. I would never have thought of doing that... And I certainly didn't interprete your code as doing so, though it is obviously what is happening now you've pointed it out.

      Mind you, I'm not exactly Mr.Paranoid in these matters, but just because you can, doesn't mean you should--leastwise not until I've found a good use for it, in which case it will be perfectly okay :)

      Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
      Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal?
      "Science is about questioning the status quo. Questioning authority".
      In the absence of evidence, opinion is indistinguishable from prejudice.
[reply]
[d/l]
        BrowserUk,
        Yeah yeah, I am not quite right in the head. I am fine with it being dangerous or broken if it was consistent, but it doesn't make sense that one version would work and the other wouldn't. If you have any other ideas I would be most appreciative.

        Cheers - L~R

[reply]

In Section Seekers of Perl Wisdom