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

use Perl Log In

Log In

[ Create a new account ]

schwern (1528)

schwern
  (email not shown publicly)
http://schwern.net/
AOL IM: MichaelSchwern (Add Buddy, Send Message)
Jabber: schwern@gmail.com

Schwern can destroy CPAN at his whim.

Journal of schwern (1528)

Wednesday February 08, 2006
04:50 AM

A short mental gauntlet for your scalar sort proposal.

[ #28621 ]

My last entry about what to do with sort in scalar context generated some new proposals. Rather than rebut them one by one, here's a short mental gauntlet for any proposal to run though:

* If sort() should do X, why not map and grep?

* Why not use a user defined function?

* Will it help in the common "return sort ..." gotcha?

* Can you think of common cases where you want to write a function which returns the entire list in list context but only do X in scalar?

Let's take, for example, the proposal to have sort return whether the list was sorted.

* It makes no sense for map and grep.

* It is easily done as a user defined function.

* It doesn't help at all with the "return sort" gotcha.

* I can't think of any reason why I'd write a function that returns either a list or the fact that some internal list is sorted.

That one's shooting fish in a barrel for example purposes. Another was to return either the first or last element of the sorted list and also to return an iterator. I leave those to the reader as its late and I'm tired.

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.
  • I'm throwing in my vote for scalar sort just returning list length.

    But why, it seems so pointless and a waste of CPU.

    The answer is that from the OUTSIDE of the method call, the user doesn't necesarily know that it went through sort, or whether the data for the list came pre-sorted.

    All they know is that they called a method and it returned a list. And the general assumption will be that scalar of it returns the quantity.

    As for wasting CPU with the sort, who's to know that the sort doesn't create some form of
    • I’d say to skip sorting and return the number of elements efficiently. It would help the common case (return sort in scalar context), and I’ve never written a sort block with side effects, can’t imagine what it’d be useful for, or have seen any such thing in anyone else’s code, whether on PerlMonks or the CPAN.

      I believe that unlike being undefined in scalar context, not sorting in scalar context is a kind of surprise that’s not very surprising, and if anyone really need

      • Someone's going to bring up side effects and point out that we're swapping one gotcha for another. The new gotcha being "sort in scalar context will not execute your code block, so if it has side effects they will not occur".

        The defense to that is that side effects in sort are so rare that this is hardly a real world gotcha. Does anyone put side effects in their sort?
        • I wouldn’t worry about that.

          First: we’re not trading gotchas:

          $ perl -le'@x = sort {++$_; $a cmp $b} qw(foo bar baz); print $_ || "nada"'
          3
          $ perl -le'$x = sort {++$_; $a cmp $b} qw(foo bar baz); print $_ || "nada"'
          nada

          This is already part of the “sort in scalar context is undefined” gotcha.

          Second – and as I’ve said –, I’ve never wanted to use side effects in a sort block, I can’t imagine a good reason that needs it, and I’ve never seen a

  • If sort() should do X, why not map and grep?

    That's easy. With map and grep, you can't determine the size of the output list purely from the size of the input list. So, having map and grep return the sizes of their output lists (if the functions were run in list context) in scalar context make sense.

    For sort to ignore its first (optional) argument, and have it act as a counting function doesn't make any sense. We already have a function that does this: the list assignment in scalar context.

    • It’s not that having sort act as a counting function is useful. It’s that no credible argument can be made against it, and that no suggestions for any sensible alternative have been forthcoming in 10 years.

  • I just tried to return an array and assign it to
    a scalar. I couldn't understand why I wasn't
    getting a reference to the array.
    • That's actually the default behavior in Perl 6. You're jumping the gun :)

      • Well, if the default behavior in Perl 6 is to en-reference the returned /l/i/s/t/ array in scalar context, perhaps with all the Perl6isms creeping into Perl 5.10 it would be consistent to "use feature :scalar_sort;" should allow "return sort {f} @A" to morph to "return [sort {f} @A]" in scalar context ?

        /me Ducks and covers, looking for nomex rug to finish the drop-and-roll with ... :-)

        undef still seems safest ...

        --
        Bill
        # I had a sig when sigs were cool
        use Sig;