[containers] Proposal: Change to the Data.Map Monoid

[David Thomas]

On Wed, May 21, 2014 at 9:47 AM, Alec <alec at deviant-logic.net> wrote:

> There is something somewhat surprising about the (Monoid v) => Monoid
> (Map k v) instance never using v's mempty.

I still find (Monoid v) => Monoid (Map k v) less surprising, but I
deliberately said Semigroup, which I believe the best choice ignoring
path dependence.



> Also (and I may have missed this argument being made already,
> apologies if so): It would be weird if Data.Map had the new monoid
> behavior but Data.IntMap didn't.  And then of course, it would be
> weird if Data.Map had it but Data.HashMap didn't.

Certainly true.


> Data.Set should probably remain the same, though it might feel
> a bit weird that Map k () wasn't isomorphic to Set k.

() forms a semigroup (and monoid) under const, so I don't see how that
isomorphism would be lost.


> Anyway, the real upshot is that unordered-containers would probably
> need to move along with containers, and that in addition to the social
> problem of moving the community in general, there would be additional
> gnashing of teeth from implementors of other map types who have
> followed the convention laid down in the "signature" for Data.Map.

Possibly, though I would be surprised if the changes wound up large
anywhere.  This doesn't touch keys, and my understanding has it that
most alternate container types differ only in their treatment of (and
requirements on) keys.