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

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/coercibl... Cheers, Oleg. On 14.02.2018 11:38, Akio Takano wrote:

Hi Oliver,

...

On Wed, Feb 14, 2018 at 8:49 AM, Akio Takano 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

On 14 February 2018 at 09:25, Oliver Charles wrote: 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@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries