Data.Monoid + collections = trouble

[ross at soi.city.ac.uk]

[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.