(A) seems good; it reduces dependencies. And the instance Monoid (Map ...) is in the module that defines Monoid which is one of the two obvious places to look S | -----Original Message----- | From: libraries-bounces@haskell.org [mailto:libraries-bounces@haskell.org] On Behalf Of | ross@soi.city.ac.uk | Sent: 25 February 2005 11:29 | To: libraries@haskell.org | Subject: Re: Data.Monoid + collections = trouble | | [moving from cvs-something to libraries] | | Sven Panne writes: | > Now that I'm finally able to build Hugs again, almost all my stuff is | > suddenly non-H98 due to Data.Monoid ('Repeated type variable "a" in | > instance head', etc.). This is due to the fact that Data.Map & friends | > are importing it, so all our shining new collection code is non-H98 | > currently. :-( This should urgently be fixed before releasing GHC 6.4; | > is moving the Monoid instances to Data.Monoid the right thing to do? | | I think the choices are: | | A) move instance Monoid (Map a) etc to Data.Monoid. | | B) make Data.Monoid portable by replacing the instance Monoid (a -> a) | with one for | | newtype Endo a = Endo { runEndo :: a -> a } | | C) make the instance Monoid (a -> a) conditionally compiled. | | D) mark the four collection modules and any that import them as | non-portable (imports Data.Monoid). | | Although A) goes against the usual policy of instance placement, it will | at least solve the problem until the next Monoid instance comes along. | | Alternative B) makes using this monoid a little more cumbersome, and if | this instance isn't in Data.Monoid it's more or less ruled out everywhere. | | Having different interfaces for different implementations (C) is deeply | unattractive. And it's not clear what to do for Hugs. | _______________________________________________ | Libraries mailing list | Libraries@haskell.org | http://www.haskell.org/mailman/listinfo/libraries