<div dir="ltr"><div dir="ltr">Hi,<div><br></div></div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Feb 15, 2020 at 1:00 PM Carter Schonwald <<a href="mailto:carter.schonwald@gmail.com">carter.schonwald@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><div dir="auto">Pedantic point : when you say semantics, it might be less confusing and more precise to performance tradeoffs.<br></div></div></blockquote><div><br></div><div>Apologies, but I'm not sure what you mean here. Could you rephrase?</div><div> </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="auto">My English language and naive preference is to assume *With functions grammar better.  Or *by. I think the *on idiom is younger relatively.  </div></blockquote><div><br></div><div>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.</div><div><br></div><div>(*By is already taken: `sortBy`, `nubBy`, `groupBy` and so on. That does seem to be already consistent.)</div><div><br></div><div>An advantage of *On is that it reflects how the functions can be defined using the `on` function:</div><div><br></div><div>    sortOn f = sortBy (compare `on` f)</div><div>    groupOn f = groupBy ((==) `on` f)</div><div><br></div><div>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.)</div><div><br></div><div>But again, neither of those points factors into my motivation here.</div><div> </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="auto"></div><div dir="auto">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 ?</div></blockquote><div><br></div><div>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.</div><div> </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="auto">  And what would make the change an improvement for software using these modules already </div></blockquote><div><br></div><div>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.</div><div><br></div><div>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.</div></div></div>