[Haskell-cafe] About mplus

[Jules Bean]

ok wrote:
> On 5 Sep 2007, at 6:16 pm, Henning Thielemann wrote:
>> I think it is very sensible to define the generalized function in 
>> terms of the specific one, not vice versa.
> 
> The specific point at issue is that I would rather use ++ than
> `mplus`.  In every case where both are defined, they agree, so
> it is rather frustrating to be blocked from using an operator
> which would otherwise have been appropriate.
> 

You can. Just write:

(++) = mplus

in your programs (or in a module called OK.Utils or OK.Prelude!) and you 
can use ++. It's not (normally) a big problem to rename functions in 
haskell.

> I am a little puzzled that there seems to be no connection between
> MonadPlus and Monoid.  Monoid requires a unit and an associative
> binary operator.  So does MonadPlus.  Unfortunately, they have different
> names.  If only we'd had (Monoid m, Monad m) => MonadPlus m...

The correct connection is:

instance (Monoid (m a), Monad m) => MonadPlus m where
   mplus = mappend
   mzero = mempty


Except, of course, we can't reasonably require that. Because for any one 
Monad m, there will be many ways to make (m a) into a Monoid, and most 
of them will not form properly behaved MonadPlusses.

The converse notion is safer:

instance MonadPlus m => Monoid (m a) where
   mappend = mplus
   mempty = mzero

And I think the main reason we don't have this version, is that we can't 
cope well with multiple instances. Many data types admit more than one 
natural Monoid, and we don't have the language features to support that 
very cleanly.

For example, there is also the Monoid:

instance Monad m => Monoid (m ()) where
   mappend = (>>)
   mempty = return ()

and these two are not necessarily compatible. In fact, on [a] (or 
rather, [()]), the former gives us addition and the latter gives us 
multiplication, viewing [()] as isomorphic to Nat. These are two very 
well known monoids on Nat.


Jules