On Fri, Feb 25, 2005 at 11:29:01AM +0000, ross@soi.city.ac.uk wrote:
[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.
C or A would either be good IMHO from a not messing up existing code point of view. Monoid is so useful, I'd prefer C and (optionally) A actually. Since the instance can't be expressed in hugs, the fact the implementations are different is unobservable and hence okay in some sense. (handwavy) John -- John Meacham - ⑆repetae.net⑆john⑈