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

[Mario Blažević]

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