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

Oliver Charles ollie at
Mon Feb 5 14:58:31 UTC 2018

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> 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> 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
>> > 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> 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
>>>> _______________________________________________
>>>> Libraries mailing list
>>>> Libraries at
>>> _______________________________________________
>>> Libraries mailing list
>>> Libraries at
>> _______________________________________________
>> Libraries mailing list
>> Libraries at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the Libraries mailing list