
Hi! 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, or is this use-case only popular in my programs? I'm asking because I have a feeling that this thing might be useful quite a lot for others also. If not -- sorry for bothering :) Cheers!

I've definitely wanted it in the past, and have even implemented limited
versions of it before. I'd be open to adding it to Data.Containers in
mono-traversable[1].
[1]
http://www.stackage.org/haddock/nightly-2015-01-20/mono-traversable-0.7.0/Da...
On Tue Jan 20 2015 at 4:34:00 AM Konstantine Rybnikov
Hi!
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, or is this use-case only popular in my programs? I'm asking because I have a feeling that this thing might be useful quite a lot for others also. If not -- sorry for bothering :)
Cheers! _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

+1
On Tue, Jan 20, 2015 at 1:45 PM, Michael Snoyman
I've definitely wanted it in the past, and have even implemented limited versions of it before. I'd be open to adding it to Data.Containers in mono-traversable[1].
[1] http://www.stackage.org/haddock/nightly-2015-01-20/mono-traversable-0.7.0/Da...
On Tue Jan 20 2015 at 4:34:00 AM Konstantine Rybnikov
wrote: Hi!
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, or is this use-case only popular in my programs? I'm asking because I have a feeling that this thing might be useful quite a lot for others also. If not -- sorry for bothering :)
Cheers! _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

Pragmatic workaround: newtype-wrap HashMap? On Tue, Jan 20, 2015 at 02:33:22PM +0200, Konstantine Rybnikov wrote:
Hi!
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, or is this use-case only popular in my programs? I'm asking because I have a feeling that this thing might be useful quite a lot for others also. If not -- sorry for bothering :)
Cheers!
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
-- Tobias Dammers - tobias@twokings.nl - 070-3457628 - www.twokings.nl Maandag t/m donderdag van 9.00 tot 17.30 Voor dringende vragen, mail naar support@twokings.nl

I do have many newtypes for different datas, and defined correct Monoid
instances for them. The problem arises when you need to convert between
them in different ways, or when you write generic HashMap-related code.
On Tue, Jan 20, 2015 at 3:44 PM, Tobias Dammers
Pragmatic workaround: newtype-wrap HashMap?
On Tue, Jan 20, 2015 at 02:33:22PM +0200, Konstantine Rybnikov wrote:
Hi!
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, or is this use-case only popular in my programs? I'm asking because I have a feeling that this thing might be useful quite a lot for others also. If not -- sorry for bothering :)
Cheers!
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
-- Tobias Dammers - tobias@twokings.nl - 070-3457628 - www.twokings.nl Maandag t/m donderdag van 9.00 tot 17.30 Voor dringende vragen, mail naar support@twokings.nl _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

Tobias Dammers
Pragmatic workaround: newtype-wrap HashMap?
I've put up a quick package wrapping `HashMap` and `Map` with the appropriate Monoid instance here [1]. In addition to the types themselves and a wide variety of `lens` and `newtype` instances, I export a selection of the more widely used functions supported by `Map` and `HashMap`. Those functions that aren't exported can be wrapped using the `Wrapping` or `Newtype` instance without too much trouble or if there's demand I wouldn't be opposed to exporting more of `Map`'s functionality. Patches accepted. Cheers, - Ben [1] https://github.com/bgamari/monoidal-containers http://hackage.haskell.org/package/monoidal-containers

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! 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. This would be more useful to have in containers and unordered-containers, rather than in separate packages, for discoverability and maintainability. Regards, Sean [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.

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
participants (6)
-
Adam Bergmark
-
Ben Gamari
-
Konstantine Rybnikov
-
Michael Snoyman
-
Sean Leather
-
Tobias Dammers