Data.Monoid + collections = trouble

[Simon Peyton-Jones]

(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 at haskell.org
[mailto:libraries-bounces at haskell.org] On Behalf Of
| ross at soi.city.ac.uk
| Sent: 25 February 2005 11:29
| To: libraries at 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 at haskell.org
| http://www.haskell.org/mailman/listinfo/libraries