On 2014-07-18 at 21:26:16 +0200, Frerich Raabe wrote: [...]
In fact, this pattern is so common that there's a convenient 'comparing' function which provides a shortcut for this use case
btw, you got the history/causality backwards in your argument: afaik, 'comparing' predates 'on', and removing the existing function 'comparing' would have been a backward incompatible change. [...]
In fact, groupBy is just one of many *By functions taking an a -> a -> Bool -- many of which are Data.List, e.g. groupBy, nubBy, deleteBy, intersectBy, unionBy. Hence, it seems plausible to define 'equating' in Data.List.
This is the same reasoning as why 'comparing' is in Data.Ord: because the module exposes a lot of *By functions taking an a -> a -> Ordering.
I don't see in what way 'equating' belonging in "Data.List" poses the "the same reasoning" of 'comparing' being in "Data.Ord". This would rather call for 'equating' belonging in "Data.Eq" (which is actually a module that's almost never imported explicitly). Consequently, I'm -1 on adding 'equating' to Data.List. However, I'm generally -0.5 on adding 'equating', as I'm not convinced 'equating' provides any significant benefit over "on (==)" (whose only downside to me is that it requires an additional "import Data.Function") I'd rather improve the existing documentation in Data.List to provide code examples involving the use of `on` for the most common tasks. Cheers, hvr