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

[Akio Takano]

Hi Oliver,

On 14 February 2018 at 09:25, Oliver Charles <ollie at ocharles.org.uk> wrote:
> On Wed, Feb 14, 2018 at 8:49 AM, Akio Takano <tkn.akio at gmail.com> wrote:
>>
>>
>> I can think of 3 reasonable definitions for (<>) for lazy maps:
>>
>> 1. (<>) = union
>> 2. (<>) = unionWith (<>)
>> 3. (<>) = Strict.unionWith (<>)
>>
>> Of these, (1) is by far the most useful operation in my experience.
>> (2) has the advantage that it seems like the most obvious choice, but
>> it's not very useful in practice. (3) is slightly more useful than
>> (2), but feels less canonical. Also (3) seems inconsistent with how
>> fmap is defined.
>
>
> I think you are very much in the minority here. (1) which we have now is
> almost never what I want. (2) is much more likely to be what I need. And of
> course, you can recover (1) with (2) by simply mapping First into every
> element.

This is not true if you consider efficiency. Mapping `First` takes
linear time. Even if you use `coerce` instead of `map First`, the
resulting map will contain thunks that were not in either of the
original maps.

>
>> So there doesn't seem to be a clear winner. Perhaps there shouldn't
>> have been a Monoid instance for maps in the first place. Given that we
>> already have one, however, it seems that the marginal gain of removing
>> it doesn't justify the cost of breaking code.
>
>
> There should be a Monoid instance, and
> http://conal.net/papers/type-class-morphisms/ argues that it should be (2).

That is an interesting paper, thanks. However, I don't think this is
going to change the fact that I almost never want to use (2) in
practice.

- Akio