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
* 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.
What will the end user see... (Score:1)
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
Re: (Score:1)
I’d say to skip sorting and return the number of elements efficiently. It would help the common case (
return sortin 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
Oh no, side effects. (Score:2)
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?
Re: (Score:1)
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 “
sortin scalar context is undefined” gotcha.Second – and as I’ve said –, I’ve never wanted to use side effects in a
sortblock, I can’t imagine a good reason that needs it, and I’ve never seen aMeta note (Score:1)
I think you wanted to link http://use.perl.org/~schwern/journal/28577 [perl.org], not http://use.perl.org/~schwern/journal/ [perl.org].
Re:Meta note (Score:2)
__ (Score:1)
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.
Re: (Score:1)
It’s not that having
sortact 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.return should do what I mean (Score:1)
a scalar. I couldn't understand why I wasn't
getting a reference to the array.
Re:return should do what I mean (Score:2)
That's actually the default behavior in Perl 6. You're jumping the gun :)
Jumping the gun Re:return should do what I mean (Score:1)
use feature :scalar_sort;" should allow "return sort {f} @A" to morph to "return [sort {f} @A]" in scalar context ?undefstill seems safestBill
# I had a sig when sigs were cool
use Sig;