Philip, Here is the documentation for Generalized List Comprehensions that mentions sortWith: https://downloads.haskell.org/ghc/latest/docs/html/users_guide/glasgow_exts.... The asymmetry between Data.List and Data.List.NonEmpty is unfortunate. I think my preference would be a non-breaking change where groupOn is added to Data.List.NonEmpty effectively as an alias for groupWith and they would both stay forever. I've not looked at the semantic difference between sortWith and sortOn, so I'm not sure which of those should be implemented with the other, but ideally, I would like to see both of them there. On Sat, Feb 15, 2020 at 1:59 PM Philip Hazelden wrote:

Hi,

On Sat, Feb 15, 2020 at 1:00 PM Carter Schonwald < carter.schonwald@gmail.com> wrote:

...

Pedantic point : when you say semantics, it might be less confusing and more precise to performance tradeoffs.

Apologies, but I'm not sure what you mean here. Could you rephrase?

...

My English language and naive preference is to assume *With functions grammar better. Or *by. I think the *on idiom is younger relatively.

I don't personally have an a particular preference between *With and *On, just a preference for consistency. My proposal isn't motivated by the english meanings of the words "with" and "on", just by (my perception of) their current usage in the ecosystem. If *With was used in most places, and *On was used in Data.List.NonEmpty, then I'd recommend switching NonEmpty to *With.

(*By is already taken: `sortBy`, `nubBy`, `groupBy` and so on. That does seem to be already consistent.)

An advantage of *On is that it reflects how the functions can be defined using the `on` function:

sortOn f = sortBy (compare `on` f) groupOn f = groupBy ((==) `on` f)

Historically, it does look like *With has been in use longer. (It looks like `sortOn` has been in base since 4.8 (2015), and in the "extra" package since the very first version 0.1 in 2014. `sortWith` has been in GHC.Exts since at least base 4.0 in 2009.)

But again, neither of those points factors into my motivation here.

...

Can I challenge you to reflect on what challenge you are trying to address with this proposal and if there’s a course of action that you feel improves everything but breaks no code ?

I suppose that simply adding the new names, marking the old ones as deprecated, and then never actually removing the old ones, would work for that.

...

And what would make the change an improvement for software using these modules already

Well, a small one is that it would make that software slightly easier to read for people who recognize the *On convention but not the *With one. There's also a chance it would make a small number of people notice that they were using a function that had different semantics from what they thought, catching bugs that hadn't previously surfaced.

But I don't think there's any version of this proposal that would accomplish this in any significant way. Improving existing software isn't really the point. _______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

-- -Andrew Thaddeus Martin

On Mon, Feb 17, 2020 at 3:59 PM Carter Schonwald 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.

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 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, wrote:

...

On Mon, Feb 17, 2020 at 3:59 PM Carter Schonwald 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@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries