[Haskell-cafe] MonoidHashMap?

[Ben Gamari]

On January 20, 2015 9:15:12 AM EST, Sean Leather <sean.leather at gmail.com> wrote:
>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