Re: A more useful Monoid instance for Data.Map
-1 on breaking the existing Monoid instance. I'd prefer either: a) A newtype for the additional Monoid instance, or b) providing an associative operator equivalent to the new Monoid instance I'm not convinced that the replacement instance is more useful, let alone useful enough to break everything depending on containers. A lot of packages both on and off Hackage depend on Edward's code, almost all of which would break as a result of this change.
-1 on breaking the existing Monoid instance. I'd prefer either:
a) A newtype for the additional Monoid instance, or b) providing an associative operator equivalent to the new Monoid instance
-1 on breaking the existing instance from me too, with a +1 for Gabriel's proposed fix. -- John Wiegley FP Complete Haskell tools, training and consulting http://fpcomplete.com johnw on #haskell/irc.freenode.net
-1, I'm against breaking the current Monoid also.
I like Gabriel's solutions, and particularly I'd like to have:
instance (Ord k, Semigroup v) => Monoid (WrappedMap k v) where
mempty = empty
mappend map0 map1 = unionWith <> map0 map1
mconcat maps = foldr (unionWith <>) empty maps
but even a Monoid constraint would be useful.
John L.
On Wed, Mar 13, 2013 at 12:59 AM, Gabriel Gonzalez
-1 on breaking the existing Monoid instance. I'd prefer either:
a) A newtype for the additional Monoid instance, or b) providing an associative operator equivalent to the new Monoid instance
I'm not convinced that the replacement instance is more useful, let alone useful enough to break everything depending on containers. A lot of packages both on and off Hackage depend on Edward's code, almost all of which would break as a result of this change.
______________________________**_________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/**mailman/listinfo/librarieshttp://www.haskell.org/mailman/listinfo/libraries
participants (3)
-
Gabriel Gonzalez -
John Lato -
John Wiegley