On January 20, 2015 9:15:12 AM EST, Sean Leather
On Tue, Jan 20, 2015 at 2:33 PM, Konstantine Rybnikov wrote:
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 (<>)`.
What I was wondering is this: is something like MonoidHashMap is desired to be in unordered-containers?
Definitely!
Agreed. I have also often needed these semantics.
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.
Things aren't quite as bad with the newtype package or the many interfaces provided by lens.
This would be more useful to have in containers and unordered-containers, rather than in separate packages, for discoverability and maintainability.
Agreed, being in containers does lower the energy barrier. In the past there have been discussions on changing the semantics of the instances provided by these packages to use monoidal accumulation. Thankfully this did not happen but adding newtypes seems like a good compromise. The trouble is that the Newtype and Wrapped instances that would make these instances usable would have to be provided outside of containers/unordered-containers to avoid adding dependencies. This slightly complicates the situation. In light of this the benefits of placing these types in their own package may outweigh those of sticking them in containers. Cheers, - Ben