[core libraries] Rename NonEmpty.groupWith/sortWIth to *On*

[chessai .]

I second Andrew's suggestion - add a function alias(es) and then keep
the old ones for a long period of time. They're not related to
typeclasses or their methods so I don't see the need to keep them
forever; anyone with an issue during updating could just resort to
`sed`. The compatibility window could be large enough to not disrupt
library authors so much, though. Since this is base that window should
be fairly large.

On Mon, Feb 17, 2020 at 11:45 PM Bryan Richter <b at chreekat.net> wrote:
>
> Adding to Philip's "things worth noting": I think anyone sophisticated enough (and lucky enough) to have their most important performance bottleneck localized to a call to sortOn instead of sortWith (or vice versa) are also sophisticated enough to implement their own version when necessary.
>
> Consistent names, on the other hand, are useful to everyone, all the time.
>
> I don't think what I just said is a surprising insight for anyone, but I thought it would be useful to state it explicitly. :)
>
> -Bryan
>
> P.s. +1 to documenting performance differences, for those rare moments they matter.
>
> On Tue, 18 Feb 2020, 1.27 Philip Hazelden, <philip.hazelden at gmail.com> wrote:
>>
>> On Mon, Feb 17, 2020 at 3:59 PM Carter Schonwald <carter.schonwald at gmail.com> wrote:
>>>
>>> It seems like the *on family in general has a nontrivial increase in space usage and the only differences have to do with application specific time vs memory tradeoffs that need to measured at the application level.
>>
>>
>> To be clear, this particular tradeoff isn't relevant for every *On function. Of the ones under discussion, it applies to sortWith, groupAllWith and groupAllWith1, but not groupWith or groupWith1.
>>
>> Some things I think are worth noting:
>>
>> * There must be lots of common functions that could choose different implementation tradeoffs, but we don't keep multiple versions of them around.
>> * The existing performance differences aren't documented. (Data.List.sortOn tells us that it only evaluates `f` once per element, but it doesn't tell us about the costs; the others don't mention performance at all.) I predict very few people currently choose between GHC.Exts.sortWith and Data.List.sortOn according to their performance needs.
>> * The Data.List.sortOn implementation is somewhat subtle and complicated. The NonEmpty.sortWith implementation is literally `sortBy . comparing` and GHC.Exts.sortWith isn't much more complicated. (`sortWith f = sortBy (\x y -> compare (f x) (f y))`; I don't know if there are reasons to prefer or disprefer this compared to `sortBy . comparing`.) If someone wants this behavior, it's not hard for them to get.
>>
>> Based on these, I don't think there's much value in deliberately[1] making sure both implementations have a name, which is why I proposed to replace `sortWith` with `sortOn` instead of keeping them both around.
>>
>> [1] Of course, there's value in not changing things once they're there. By "deliberately", I mean that if we weren't already in this situation, and someone proposed adding a separate function that was semantically equivalent to `sortOn` but implemented as `sortBy . comparing`, I don't think that would see much support.
>> _______________________________________________
>> Libraries mailing list
>> Libraries at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries