<div dir="ltr">Hello Philip, clc gets / reads libraries anyways, no need to double email : )<div><br></div><div>perhaps i'm missing something, are we talking about the specifics of the implementations while stilling having the same observable pure results, OR something different?</div><div><br></div><div>When does each have a clear performance win? </div><div><br></div><div>at least from my native english speaker perspective, sortWith is better grammar. Are you describing a choice of performance characteristics related to *On vs *With functions?</div><div><br></div><div>also, could you spell out which reference implementations of which convention enshrine which meanings you have in mind? </div><div><br></div><div>I dont see a good reason to change the names that are provided from one to the other. Are you merely making the case that both styles should be exported from certain places, and that a particular choice of evaluation trade offs be enshrined by the respective naming convention?</div><div><br></div><div><br></div><div>please spell this out more concretely, i'm not able to decode what you mean unambiguiously. Just changing the names of some functions in base in isolation breaks code for no reason, so if you are arguing for that, i'm gonna say nope :) </div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Feb 12, 2020 at 12:58 PM Philip Hazelden <<a href="mailto:philip.hazelden@gmail.com">philip.hazelden@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Hi,</div><div><br></div><div>I'm referring to these functions: `sortWith` `groupWith` `groupAllWith` `groupWith1` `groupAllWith1`.<br></div><br>The `On` suffix is more common for such things, and I anticipate it's what most users will normally expect them to be named.<br><br>Additionally, the name `groupWith` is potentially misleading. That name is also used in GHC.Exts[1], for a function with the same type signature but different semantics. `GHC.Exts.groupWith` sorts its input list, unlike `NonEmpty.groupWith` or `Data.List.Extra.groupOn`. (In NonEmpty, we have `groupAllWith` for group-with-sort. So we have three names, two semantics, and no consistency.)<br><br>According to <a href="https://github.com/ekmett/semigroups/pull/52" target="_blank">https://github.com/ekmett/semigroups/pull/52</a>, `With` was chosen because:<br><br>> The preferred vocabulary for On here is With to match the combinators in GHC.Exts from the "comprehensive comprehensions" paper. That'd make it so that if you use these with comprehensive comprehensions turned on and RebindableSyntax turned on then you'd get these combinators.<br><br>But I don't see anything in the docs which suggests that the TransformListComp extension[2] uses these functions implicitly, or interacts with RebindableSyntax[3]. So perhaps I'm missing something, but my guess is this is no longer a concern.<br><br>The case for `sortWith` is weaker, since it might trip people up but it won't introduce unexpected semantics. There's also a counter argument in <a href="https://gitlab.haskell.org/ghc/ghc/issues/12044" target="_blank">https://gitlab.haskell.org/ghc/ghc/issues/12044</a>. `Data.List.sortOn` only computes the mapping function once for each element, while `GHC.Exts.sortWith` computes it every time it does a comparison but uses fewer allocations. `Data.NonEmpty.sortWith` acts like the latter. My suggestion would be to replace it with a `sortOn` implemented like `Data.List.sortOn`, but I also don't think it would be terrible to have both, or even to just rename and leave this small inconsistency. If there's no agreement on this function, I think it would be worth renaming the group functions anyway.<br><br>And so I propose, in descending order of how much I care:<br><br>1. Rename the group functions to be named "On" instead of "With".<div><br><div>2. Rename `sortWith` to `sortOn` In the case of `sortWith`, also reimplement it as<br><br>3. Reimplement `sortOn` as</div><div><br> sortOn :: Ord b => (a -> b) -> NonEmpty a -> NonEmpty a<br> sortOn = fmap snd . sortBy (comparing fst) . fmap (\x -> let y = f x in y `seq` (y, x))<br><br>I assume the process here would be to leave the existing names for a time with deprecation warnings, and then remove them a few versions down the line.<br><div><br></div><div>[1] <a href="https://hackage.haskell.org/package/base-4.12.0.0/docs/GHC-Exts.html#v:groupWith" target="_blank">https://hackage.haskell.org/package/base-4.12.0.0/docs/GHC-Exts.html#v:groupWith</a><br></div><div>[2] <a href="https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/glasgow_exts.html#extension-TransformListComp" target="_blank">https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/glasgow_exts.html#extension-TransformListComp</a></div><div>[3] <a href="https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/glasgow_exts.html#extension-RebindableSyntax" target="_blank">https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/glasgow_exts.html#extension-RebindableSyntax</a></div></div></div><div><br></div><div>Best,</div><div>Phil</div></div>
<p></p>
-- <br>
You received this message because you are subscribed to the Google Groups "haskell-core-libraries" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an email to <a href="mailto:haskell-core-libraries+unsubscribe@googlegroups.com" target="_blank">haskell-core-libraries+unsubscribe@googlegroups.com</a>.<br>
To view this discussion on the web visit <a href="https://groups.google.com/d/msgid/haskell-core-libraries/CALB5dS-5qKjK6rmvFg2TuZ_3HvPtPyuGzsTrVO8adAnX1zovdg%40mail.gmail.com?utm_medium=email&utm_source=footer" target="_blank">https://groups.google.com/d/msgid/haskell-core-libraries/CALB5dS-5qKjK6rmvFg2TuZ_3HvPtPyuGzsTrVO8adAnX1zovdg%40mail.gmail.com</a>.<br>
</blockquote></div>