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@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@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@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@joachim-breitner.de
  http://www.joachim-breitner.de/

_______________________________________________
Libraries mailing list
Libraries@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
Libraries@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
Libraries@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries