Proposal: add 'equating' function to Data.List

[John Lato]

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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20140721/868260f8/attachment.html>