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

Oliver Charles ollie at
Mon Feb 5 14:51:52 UTC 2018

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>

> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the Libraries mailing list