generalize type of Data.Set.unions from List to Foldable
Evan Laforge
qdunkan at gmail.com
Sun Feb 4 23:19:14 UTC 2018
If it were removed I would just move the definition to my local
Util.Map and keep using it. So, speaking for myself only, the result
is the same, just with a less convenient name, and a lengthy period of
deprecation in between.
Is there some kind of general agreement about how important a change
has to be to be worth breaking things? Clearly people are not willing
to commit to Java style never break things, but there is a threshold
somewhere. If there's no general consensus, then at least this change
is below my personal threshold.
I'd put buggy, or shown to be error prone in practice, or leads to
significant or error prone boilerplate on the "break" side, and
redundant or not general on the "do not break" side. #ifdef is error
prone boilerplate too.
On Feb 4, 2018 12:11 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
>
More information about the Libraries
mailing list