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

[Oliver Charles]

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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20180205/ca45b994/attachment.html>