Re: Proposal: Remove Semigroup and Monoid instances for Data.Map, Data.IntMap, Data.HashMap

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 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.