Proposal: add 'equating' function to Data.List

[David Feuer]

Eq instances should only be used for conceptual equality, and never just
for convenience applying some function or other. I don't think that makes
any sort of argument for "equating", though.
On Jul 20, 2014 8:46 PM, "John Lato" <jwlato at gmail.com> wrote:

> The utility of the proposed "equating" extends far beyond simply using it
> with groupBy.  Just last week I used "on (==)" as part of a complicated
> boolean expression.
>
> That said, I just want to be clear that I'm understanding Greg properly.
>  Are you advocating that one should generally create a newtype+Eq instance
> rather than using "on (==)"?  What is the benefit of this approach?  The
> only one I can think of is that it makes the standard libraries smaller,
> which seems like a rather small gain considering that you've changed a
> 7-character expression into multi-line boilerplate for everyone, hampering
> readability in the process.  Is there something I'm missing here?
>
> (Currently +0 on the proposal)
>
> John L.
>
>
> On Mon, Jul 21, 2014 at 8:27 AM, Greg Weber <greg at gregweber.info> wrote:
>
>> I am -1 on things that encourage converting Eq to Bool rather than just
>> using Eq directly.
>>
>> Is there a use case for group that is not satisfied by groupOn with a
>> newtype with an Eq instance?
>> Granted, a newtype may be heavy-weight, but I feel that the current group
>> should be an escape hatch in the rare case that groupOn does not suffice,
>> not something we codify via Fairbairn threshold because that is the only
>> API that exists today. I can create a separate proposal for adding groupOn,
>> etc.
>>
>>
>> On Fri, Jul 18, 2014 at 12:57 PM, Greg Weber <greg at gregweber.info> wrote:
>>
>>> I think the `By` functions that expect a Bool are all cumbersome because
>>> they are too flexible. 100% of the time I personally use these functions I
>>> want to use Ord or Eq.
>>> What I would like to see is a function groupOn next to groupBy.
>>>
>>> groupOn :: Eq b => (a -> b) -> [a] -> [[a]]
>>>
>>> Then equating is no longer needed, and one just writes: groupOn snd
>>> I believe this style also gives better opportunity for optimization
>>> (Scwartzian transform).
>>>
>>> Of course, this function is still problematic because it operates only
>>> on lists and does not group over the entire list, but those are separate
>>> issues.
>>> All of this is solved in mono-traversable right now by the groupAllOn
>>> function [1]
>>>
>>> [1]
>>> http://hackage.haskell.org/package/mono-traversable-0.6.0.4/docs/Data-Sequences.html
>>>
>>>
>>> On Fri, Jul 18, 2014 at 12:26 PM, Frerich Raabe <raabe at froglogic.com>
>>> wrote:
>>>
>>>> Hi,
>>>>
>>>> A common use case for 'on' (from Data.Function) is to use it with
>>>> 'compare', e.g. 'compare `on` snd'. In fact, this pattern is so common that
>>>> there's a convenient 'comparing' function which provides a shortcut for
>>>> this use case such that one can write
>>>>
>>>>   sortBy (comparing snd)
>>>>
>>>> instead of
>>>>
>>>>   sortBy (compare `on` snd)
>>>>
>>>> I think another common use case is to use 'on' together with (==) as in
>>>>
>>>>   groupBy ((==) `on` snd)
>>>>
>>>> In a similiar vein as with 'comparing', I think it would be nice if
>>>> there was a function which encapsulates this use case, like
>>>>
>>>>   equating :: Eq b => (a -> b) -> a -> a -> Bool
>>>>   equating = on (==)
>>>>
>>>> such that one can write
>>>>
>>>>   groupBy (equating snd)
>>>>
>>>> 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.
>>>>
>>>> - Frerich
>>>>
>>>> _______________________________________________
>>>> Libraries mailing list
>>>> Libraries at haskell.org
>>>> http://www.haskell.org/mailman/listinfo/libraries
>>>>
>>>
>>>
>>
>> _______________________________________________
>> Libraries mailing list
>> Libraries at haskell.org
>> http://www.haskell.org/mailman/listinfo/libraries
>>
>>
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20140720/3b2423ef/attachment-0001.html>