Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • Sort in scalar context should return bunnies. Then everybody would be happy. Bunnies are fluffy and cute. If you don't think that, you'll find that they're awfully tasty. If you're a vegetarian, they conveniently return a ratio of already sorted pairs. You can't lose!

  • In the meanwhile, it sounds like a good thing to add to Perl::Critic [cpan.org]...

    -Dom

    • I'd second that, as it is what I was going to suggest. I see return sort .. in a same way as return undef just because one doesn't want something to be returned. It's ambiguous and in my opinion the developer should be aware of that. Would be a lot easier with a Perl-Critic policy, though I don't know how spread that already is "in the wild."
      --
      Ordinary morality is for ordinary people. -- Aleister Crowley
  • It’s interesting that neither argument against returning the list length presents a use case that would be precluded; both just argue on principles. And the leave-it-undefined stance takes the same basic position.

    The magnitude of sorted pair ratios != 1.0 is meaningless, so that’s not even as useful as keys in scalar context.

    We have exactly one real-world use case, return sort @foo, so there is exactly one meritorious argument, and it has no compelling counter. Why is anyone even arguing abo

  • I've always thought the obvious behavior would be to return the first element. It doesn't gain much (saves you typing two parens, maybe), but it's just what I always thought made sense...
    --
    rjbs
  • First of all, I use 'return sort ...' in my code on a regular bases. I don't consider this a bug. If I write a function that's supposed to return a (sorted) list, and someone calls the function in scalar context, then it's the calling code that's buggy, not the subroutine. If I wanted the function to behave sensible when used in scalar context, I'd make it so. But I doubt that it would then return the number of elements of the list. I'm with rjbs on this one - the first (or last) element would be more usefu

    • If I wanted the function to behave sensible when used in scalar context, I'd make it so.

      The other way to look at that is "I want my functions to behave insensibly in scalar context unless I remember to make it so" which strikes me as a little peevish and definately not DWIM.

      That aside, here's something more concrete--how do you do that? Take this sample for example, which is much like the code I recently stumbled over...

              return sort { $a cmp $b }
             

      • The other way to look at that is "I want my functions to behave insensibly in scalar context unless I remember to make it so" which strikes me as a little peevish and definately not DWIM.

        That sounds like for all functions that I design to return a list, I should take the trouble of figuring out what it they should do in list context.

        Sorry, but I pass. For functions where it makes sense, I do so. But for many, I won't. Consider the context to be a pre-condition - just like the arguments being passed in.

    • That would require of Perl to do extra magic when it encounters return sort, and it’s non-reentrant. I vote no. If you want an iterator, then an iterator object/closure should be returned. Let’s not create more instances of the each trap.

  • My vote for the meaning of sort in scalar context is to return whether the list was already sorted.

    unless( sort @list ) {
        # @list is not sorted, deal with it...
        ...
    }

    If you want to go beyond a simple boolean, the index of the first out of order element sounds a lot more useful than the proprtion of sorted neighbours - and, like the boolean result, it can short circuit the scan of the list as soon as an out of order pair is found.

    • to return whether the list was already sorted

      An is_sorted @list predicate would be an interesting builtin/XS/Inline function, and should run faster than sort (if coded equally well). It should run about the same speed as a least @list sort-variant optimized to return (sort @_)[0].

      However, I'm not sure is_sorted should be called scalar sort, that doesn't seem any better than calling least as scalar sort. Changing sort from verb-transitive to verb-predicate when going from list to scalar context is rather

      --
      Bill
      # I had a sig when sigs were cool
      use Sig;
  • All of the return sort's in the debugger are called in list context - Term::Readline's completion function in most cases, and a similar bit of code in the options handlling. It's probably not worth patching it.
    • Three times a year, a new person is caught by surprise by sort in scalar context. The rest of the time, noone cares or notices. Why not spare these three guys the surprise and just give it a reasonable default? Noone will notice if it’s patched.