Cont as Monoid

[Conor McBride]

Hi Conal

Conal:
 > I'd like to see the following addition to Control.Monad.Cont in mtl:
 >
 > instance Monoid r => Monoid (Cont r a) where
 >     mempty         = Cont mempty
 >     m `mappend` m' = Cont (runCont m `mappend` runCont m')

Does newtype deriving work here?

Stefan:
 > (My 2 cents: Why not mempty = return mempty; mappend = liftM2  
mappend ?
 > Instances are best if unambiguous.)

Conal:
 > I sure don't know how to resolve these situations of more than one  
credible
 > instance.  I'm seeing more & more of them.

My usual rule of thumb is that inherent natural monoidal structure  
should have
a higher priority than just applicative lifting of monoidal structure  
from the
value type. Here it's a bit harder to call because it's a choice of  
two lifts,
but I'd suggest that (Cont r) has natural monoidal structure if r is  
a monoid,
and hence this should take precedence over the applicative lifting  
(which is
what liftM2 does, but with too restrictive a type).

I guess my fairly feeble reason for this rule of thumb is that it  
fits with
what one would expect for []. It may also be to do with the way I  
read types:
when I see a type application (f t), I think of it as an f-like thing  
with
t-like details, hence the natural properties of f are somehow the more
significant. Moreover, preferring the f-specific thing is no big deal  
if you
have a cheap and uniform way to get the other thing (eg, liftA2 or idiom
brackets). The f-specific thing usually requires special  
consideration, hence
benefits most from overloading.

So I'm with you on this one.

All the best

Conor