I've been thinking about making a data type an instance of MonadPlus. From the Haddock documentation at haskell.org, I see that any such instance should satisfy mzero `mplus` x = x x `mplus` mzero = x mzero >>= f = mzero v >> mzero = mzero but is that all there is to it? Are there no other requirements for MonadPlus to make sense? I also wondered why, once MonadPlus was added to the language, the definition of ++ wasn't changed to (++) = MonadPlus (with the MonadPlus instance for [] defined directly). Aside from getting msum and guard, is there any point in bothering to make something an instance of MonadPlus?

On 9/4/07, ok wrote:

I've been thinking about making a data type an instance of MonadPlus. From the Haddock documentation at haskell.org, I see that any such instance should satisfy

mzero `mplus` x = x x `mplus` mzero = x mzero >>= f = mzero v >> mzero = mzero

but is that all there is to it? Are there no other requirements for MonadPlus to make sense?

Also, mplus has to be associative. I.e. (a `mplus` b) `mplus` c == a `mplus` (b `mplus` c)

I also wondered why, once MonadPlus was added to the language, the definition of ++ wasn't changed to (++) = MonadPlus (with the MonadPlus instance for [] defined directly).

You mean (++) = mplus. I've wondered that too. Similarly, one should define map = fmap. And a lot of standard list functions can be generalized to MonadPlus, for example you can define filter :: (MonadPlus m) => (a -> Bool) -> m a -> m a (This is not the same as filterM.)

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. Of course it is not a show-stopper; I can simply make something else up. 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...

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

G'day all. Slight nit... Quoting ok :

I've been thinking about making a data type an instance of MonadPlus. From the Haddock documentation at haskell.org, I see that any such instance should satisfy

mzero `mplus` x = x x `mplus` mzero = x mzero >>= f = mzero v >> mzero = mzero

As discussed previously, that last "law" is wrong. In particular, it can't be true of any monad transformer: lift fireMissiles >> mzero /= mzero

but is that all there is to it? Are there no other requirements for MonadPlus to make sense?

It's proposed to split nondeterminism-like monads and error catch-like monads to allow for some other laws: http://haskell.org/haskellwiki/MonadPlus_reform_proposal Cheers, Andrew Bromage