<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Jan 20, 2015 at 2:33 PM, Konstantine Rybnikov wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div>I'm working with a lot of HashMap's and it's very frustrating how many times I've "lost" my data because of usage of either a Monoid instance of a HashMap (which is defined as H.union, which, upon collision, takes value from first hm and discards from second), or just using fromList in the wrong place. Whereas the data I'm working is is mostly defined as (Monoid v => HashMap k v), so what I need "by default" is actually something like `H.unionWith (<>)`.<br><br></div>What I was wondering is this: is something like MonoidHashMap is desired to be in unordered-containers?</blockquote></div><br>Definitely!</div><div class="gmail_extra"><br></div><div class="gmail_extra">I have often wished the Monoid instances for both HashMap and Map had `mappend = unionWith mappend` [1]. It may be trivial to write a newtype wrapper and Monoid instance, but it's tedious to use many library functions with that wrapper.</div><div class="gmail_extra"><br></div><div class="gmail_extra">This would be more useful to have in containers and unordered-containers, rather than in separate packages, for discoverability and maintainability.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Regards,</div><div class="gmail_extra">Sean</div><div class="gmail_extra"><br></div><div class="gmail_extra">[1] Assuming that was already the case, I believe we could get the `mappend = union` approach by coercing the value type to Data.Monoid.First. Of course, there are other useful monoids for the taking, as well.</div></div>