Cont as Monoid
ctm at cs.nott.ac.uk
Sun Sep 9 07:58:25 EDT 2007
> 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?
> (My 2 cents: Why not mempty = return mempty; mappend = liftM2
> Instances are best if unambiguous.)
> I sure don't know how to resolve these situations of more than one
> instance. I'm seeing more & more of them.
My usual rule of thumb is that inherent natural monoidal structure
a higher priority than just applicative lifting of monoidal structure
value type. Here it's a bit harder to call because it's a choice of
but I'd suggest that (Cont r) has natural monoidal structure if r is
and hence this should take precedence over the applicative lifting
what liftM2 does, but with too restrictive a type).
I guess my fairly feeble reason for this rule of thumb is that it
what one would expect for . It may also be to do with the way I
when I see a type application (f t), I think of it as an f-like thing
t-like details, hence the natural properties of f are somehow the more
significant. Moreover, preferring the f-specific thing is no big deal
have a cheap and uniform way to get the other thing (eg, liftA2 or idiom
brackets). The f-specific thing usually requires special
benefits most from overloading.
So I'm with you on this one.
All the best
More information about the Libraries