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.
  • 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;