On 2018-02-14 10:07 AM, David Feuer wrote:

This, of course, is another argument for Kris's idea of just offering
a pile of newtypes, each with their own Semigroup (and sometimes
Monoid) instance.

        I would gladly use disjointUnion where appropriate, but I don't think I'd ever use a newtype providing the same effect. Why? There are two situations when I depend on union* or (<>) on maps:

1. Directly at the top level, where I can use either union or (<>) on two known maps. In this situation I often use (<>) only because (a <> b) is shorter and easier to read then (union a b), but that criterion points the other way if I have to say (fromDisjoint (Disjoint a <> Disjoint b)) instead of (disjointUnion a b).

2. Indirectly when folding a Foldable collection of maps. In this case I have no choice but to use (<>), but I really can't think of any occasion when all maps in the collection are guaranteed to have distinct keys.

On Wed, Feb 14, 2018 at 10:03 AM, Joachim Breitner
<mail@joachim-breitner.de> wrote:

Hi,

Am Mittwoch, den 14.02.2018, 09:47 -0500 schrieb Mario Blažević:

         I understand it's hard to grep, but can you guess how many of those
40-80 uses of (<>) with the union meaning actually depend on the
left-biased semantics? I've looked at my code, and it turns out that
wherever this operation appears, the two maps are guaranteed to have
distinct keys.

does this indicate the need for

     disjointUnion :: IntMap a -> IntMap a -> IntMap a

that throws an error when the maps are not disjoint? (run-time error
only, because we are not doing theorem proving here…)

One can get the effect with

     unionWith (error "not disjoint)

of course (and I have done so), but having `disjointUnion` in the API
might remind people that they have to think about which variant they
want.

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