generalize type of Data.Set.unions from List to Foldable

[Oliver Charles]

Oh, the comment about maintenance cost wasn't a response directly to you,
just that it had been mentioned in this thread.

I'm ok with generalising unions to work over any Foldable.

On Mon, Feb 5, 2018 at 2:56 PM, David Feuer <david.feuer at gmail.com> wrote:

> I'm not concerned about the maintenance cost. I'm more concerned about the
> size of the API. People tend to get lost in the sea of functions in
> containers. But it sounds like lots of people are attached to unions, so
> what do y'all think about generalizing its type?
>
> On Feb 5, 2018 9:52 AM, "Oliver Charles" <ollie at ocharles.org.uk> wrote:
>
>> unions also describes intent clearly. My intention is to take the union
>> of a collection of sets. That might well correspond with a fold, but that's
>> an implementation detail - and not one that I particularly care about. On
>> top of that, when people read my code, I want them to understand that I
>> intend to take the unions of a collection of sets, rather than having them
>> figure out what it is I'm doing by using foldl.
>>
>> I don't really see the harm in keeping unions, and I don't see the
>> advantage in removing it. If we're arguing that unions is so simple to
>> write, then the argument that deleting code will improve maintainability
>> doesn't hold - because apparently it's so simple we're not going to
>> introduce bugs in containers. If you don't agree with that reasoning, then
>> apparently unions is sufficiently complicated to write that it *should* be
>> in the containers library.
>>
>> On Mon, Feb 5, 2018 at 2:46 PM, Jan-Willem Maessen <jmaessen at alum.mit.edu
>> > wrote:
>>
>>> The biggest argument in favor of unions and unionsWith is that, while
>>> they're easy to write, they're also very easy to write wrong – for example
>>> by using fold instead of foldl' as described rather well in the
>>> conversation so far.  When I use a function like unions I expect to get an
>>> implementation better than the one I'd come up with on my own at the spur
>>> of the moment, and deciding what strictness is more efficient in this case
>>> is actually a little bit subtle.
>>>
>>> -Jan-Willem Maessen
>>>
>>> On Sun, Feb 4, 2018 at 3:09 PM, Joachim Breitner <
>>> mail at joachim-breitner.de> wrote:
>>>
>>>> Hi,
>>>>
>>>> Am Samstag, den 03.02.2018, 20:44 -0500 schrieb David Feuer:
>>>> > It is fold, although fold is not so great for lists in this context.
>>>> It's also foldl' union Set.empty, which is better for lists, and probably
>>>> also for balanced trees. I initially thought that we should surely
>>>> generalize, but now another alternative comes to mind: remove. As a
>>>> containers maintainer, I believe we should either:
>>>> >
>>>> > 1. Generalize as proposed, or
>>>> > 2. Deprecate and remove.
>>>> >
>>>> > I'm currently somewhat in favor of the second option.
>>>>
>>>> please don’t remove!
>>>>
>>>> …is first reaction. Now I just have to rationalize my gut feeling…
>>>>
>>>> I like the readability of it in code, it is more descriptive. It is an
>>>> important analogue to unionsWith. If we remove unions because of fold,
>>>> shouldn’t we also remove union because of (<>)?
>>>>
>>>>
>>>> Cheers,
>>>> Joachim
>>>>
>>>> --
>>>> Joachim Breitner
>>>>   mail at joachim-breitner.de
>>>>   http://www.joachim-breitner.de/
>>>>
>>>> _______________________________________________
>>>> Libraries mailing list
>>>> Libraries at haskell.org
>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>>>>
>>>>
>>>
>>> _______________________________________________
>>> Libraries mailing list
>>> Libraries at haskell.org
>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>>>
>>>
>>
>> _______________________________________________
>> Libraries mailing list
>> Libraries at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20180205/21e84846/attachment.html>