Data.Monoid + collections = trouble

[John Meacham]

On Fri, Feb 25, 2005 at 11:29:01AM +0000, ross at 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⑈