Re: [containers] Proposal: Change to the Data.Map Monoid
On Wed, May 21, 2014 at 12:11 PM, David Thomas wrote:
For what it's worth, I'd find Semigroup v => Monoid (Map k v) both more useful and less surprising
...than the current unqualified monoid instance for all maps 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. Data.Set should
There is something somewhat surprising about the (Monoid v) => Monoid (Map k v) instance never using v's mempty. probably remain the same, though it might feel a bit weird that Map k () wasn't isomorphic to Set k. 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. -A
On Wed, May 21, 2014 at 9:47 AM, Alec
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.
participants (2)
-
Alec -
David Thomas