in reply to Sorting, recursion, and tail-call optimizations

See implicit sort disables a chained subroutine?. Same problem and answer I think?


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: Sorting, recursion, and tail-call optimizations

Replies are listed 'Best First'.
Re^2: Sorting, recursion, and tail-call optimizations
by Limbic~Region (Chancellor) on Jan 06, 2006 at 17:06 UTC
    BrowserUk,
    Maybe - but I don't think so. First, I don't have a chained subroutine. I am calling sort with a user defined sort routine and a list only. There is no additional routine to modify the list before passing it to sort that could get confused as the comparator. Also, your post indicated that by b0rk it didn't produce any results. In my case, I am getting a pop up saying that perl encountered a problem and needed to close requesting a report be sent to M$.

    Cheers - L~R

      Perhaps not then, though I still think it is to do with the capriciousness of the dwimery that allows (and actually requires), you to supply a bareword for the user sub instead the more normal and rational \&usersub in place of the bare block.

      I always use an inline block for sorting because the rules surrounding when you can get away with using a bareword usersub seem to be undocumented and vary according to the phases of the moon as best as I can discern :)

      Much the same as I always use a bareblock with map and grep in preference to a undelimited expression, despite it's creating an extra level of scope. It is just much to easy for the significance of that comma separating the code from the list to get lost, especially if the complexity of the expression increases.


      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.
        BrowserUk,
        I am not sure I agree. The user defined sub is getting called in both cases as a comparator and there doesn't appear to be any ambiguity. By putting a print statement inside the sub, I can count how many times it is called. 52 for the working version and 2 for the b0rk version before it blows up.

        Now here is where it gets interesting, if I include $a and $b in the print statement I discover that in the first call both variables are set to two different array refs (as expected). On the second call (the one that blows up), neither variable is defined???

        sub my_sort { print "hello there $a $b\n"; my $i = $_[0] || 0; ... } __END__ hello there ARRAY(0x1868244) ARRAY(0x1868298) Use of uninitialized value in concatenation (.) or string at ... Use of uninitialized value in concatenation (.) or string at ... hello there *** BOOOOM ***

        Cheers - L~R