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

[Oleg Grenrus]

I agree with Oliver, was just writing the very same.


`Map.map First = Map.map coerce = coerce`

i.e. mapping First is _zero-cost_, thanks to the fact `v` in `Map k v`
has represenational role.
(If there aren't RULES in place, it's a bug).

See Zero-Cost coercions in Haskell
https://www.microsoft.com/en-us/research/wp-content/uploads/2016/07/coercible.pdf

Cheers, Oleg.


On 14.02.2018 11:38, Akio Takano wrote:
> 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
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries