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

Thanks, Conor. I like your reason of appealing to f structure over t structure in (f t). And, yes I'd forgotten to mention that the monoid instance I suggested is exactly the one that holds for the representation (under the newtype). Deriving works just fine here: deriving instance Monoid (Cont r a) Cheers, - Conal On 9/9/07, Conor McBride wrote:

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

Ashley Yakeley wrote:

Conor McBride wrote:

...

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.

Monoid is a bit ridiculous as a class, as there are frequently several useful monoids on a type, leading to a collection of ugly wrapper newtypes.

Monoid ought to be a type, in my view. And each of those wrapper classes can be replaced by a value in that type.

Would you care to elaborate this idea? Do you mean a record with two functions? Cheers Ben

On 9/21/07, Iavor Diatchki wrote:

Hi,

On 9/18/07, Benjamin Franksen wrote:

...

Ashley Yakeley wrote:

...

Monoid ought to be a type, in my view. And each of those wrapper classes can be replaced by a value in that type.

Would you care to elaborate this idea? Do you mean a record with two functions?

Here is how you can do that:

data Monoid a = Monoid { mempty :: a, mappend :: a -> a -> a }

Alternatively, class Monoid a where type Carrier a mempty :: a -> Carrier a mappend :: a -> Carrier a -> Carrier a -> Carrier a data Sum a instance Num a => Monoid (Sum a) where type Carrier (Sum a) = a mempty _ = 0 mappend _ = (+) data Lift f a instance (Monoid a, Applicative f) => Monoid (Lift f a) where type Carrier (Lift f a) = f (Carrier a) mempty _ = pure (mempty (undefined::a)) mappend _ = liftA2 (mappend (undefined::a)) data Writer o a = Writer (Carrier o) a instance (Monoid o) => Monad (Writer o) where return a = Writer (mempty (undefined::o)) a (Writer o1 a) >>= f = let Writer o2 b = f a in Writer (mappend (undefined::o) o1 o2) b -- Dave Menendez http://www.eyrie.org/~zednenem/

"Cont (Endo b) a" is the usual backtracking monad.

It is? Would you say more about that? A pointer would be fine. I'm wondering what the role of Endo is here. Cheers, - Conal On 9/9/07, David Menendez wrote:

On 9/8/07, Conal Elliott wrote:

...

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')

Alternatively,

instance Monoid r => MonadPlus (Cont r a) where mzero = Cont mempty mplus a b = Cont $ runCont a `mappend` runCont b

"Cont (Endo b) a" is the usual backtracking monad.