#1460: Problem with Monoid instance of Data.Map -------------------------------------+------------------------------------- Reporter: ahey@… | Owner: (none) Type: proposal | Status: closed Priority: normal | Milestone: Not GHC Component: libraries/base | Version: 6.6.1 Resolution: fixed | Keywords: Data.Map | Monoid Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by andrewthad): I'd like to bring this up again. Especially since `Semigroup`, in the next two years, is going to end up as a superclass of `Monoid`. The even better instance would be: {{{ instance (Ord k, Semigroup v) => Monoid (Map k v) }}} In the mailing list that Joachim linked to, this kind of change seemed to attract pretty broad support. I think the only reasonable way to make this change without introducing silent breakage would be to release a `containers-0.6` in which `Map` has no `Monoid` instance. Then, in `containers-0.7`, the new instance would be introduced. This is precisely what Henning proposed in https://mail.haskell.org/pipermail/libraries/2012-April/017749.html, and I think it's the best option available for switching out this instance. These two release would need to be at least a year apart. We would probably like for their to be a stackage lts between them that had `containers-0.6`. And we would probably want to wait for `Semigroup` to actually become a superclass of `Monoid` in `base` before releasing `semigroups-0.7`, just because it's really annoying when you end up with a `(Semigroup v, Monoid v)` constraint sometimes. I would like to draw attention to the two arguments against making this change: 1. It would break a lot of other packages 2. The behavior value-combining `Monoid` instance is easily recovered by using `unionWith`. This reasoning roughly motivates this post: https://mail.haskell.org/pipermail/libraries/2012-April/017745.html Concerning argument (1), I offer no rebuttal. I'll only point out that, with stackage, we now have a somewhat convenient way to attempt to measure the breakage. But, no one has ever done this, and it might be worth looking into. Argument (2) I would like to challenge. In http://www.haskellforall.com/2014/07/equational-reasoning-at-scale.html, Gabriel Gonzalez uses, in a practical way, the behavior of data types that can lift monoidal value into another monoid. Things like: {{{ instance Monoid a => Monoid (IO a) instance (Monoid a, Monoid b) => Monoid (a,b) instance Monoid b => Monoid (a -> b) }}} These are useful because they give us `Monoid` instances for types like: {{{ Int -> Bool -> Char -> IO ([Text],Ordering) }}} The value-combining `Monoid` instance for `Map` is in this same spirit. It would allow us to trivially combine nested map with types like this: {{{ type M = Map Int (Map Char (Map PersonId (Map ItemId [Text]))) mappend :: M -> M -> M }}} This behavior can be recovered by `unionWith`, but it's a length explicit lifting: {{{ deepAppend :: M -> M -> M deepAppend = unionWith (unionWith (unionWith (unionWith (<>)))) }}} I plan on continuing this tomorrow. I have a little more to say. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/1460#comment:8 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler