Good point; I suppose the constraint m /= _|_ should be added to the law. ajb@spamcop.net wrote:

The problem is this "law":

m >>= \k -> mzero === mzero

I think this "law" is untrue for _all_ MonadPlus instances, and you can trivially check this by setting m to bottom.

Cheers, Andrew Bromage

G'day all. Quoting Iavor Diatchki :

This is not enough, at least in some cases. Consider lists, and m being an infinite list, e.g. [1..] Then we need that the inifinte concatenation of a empty lists gives us the empty list which is not the case.

It also doesn't work for monad transformers (e.g. Ralf Hinze's backtracking transformer) when stacked over monads like IO. I say we remove the "law" altogether. It clearly causes problems, and if you use the Hughes/Hinze method for deriving the monads, it turns out that you don't need it anyway. Cheers, Andrew Bromage

Ashley Yakeley writes:

In article , Jules Bean wrote:

...

So, anyone? What are the laws that MonadPlus is supposed to satisfy?

These are what I think they should be:

mplus mzero a = a mplus a mzero = a mplus (mplus a b) c = mplus a (mplus b c) mzero >>= a = mzero (mplus a b) >>= c = mplus (a >>= c) (b >>= c)

These are what is found in Martin and Gibbons paper, even as they're wrong that Maybe can follow them.

<http://web.comlab.ox.ac.uk/oucl/work/jeremy.gibbons/publications/ tactics

..pdf>

Philip Wadler listed those as the laws he "would usually insist on" in a 1997 message[1]. [1] http://www.dcs.gla.ac.uk/mail-www/haskell/msg00057.html He also mentions two other possible, but problematic, laws: m >>= \x -> mzero == mzero m >>= \x -> k x `mplus` h x == m >>= k `mplus` m >>= h The first doesn't hold when m is bottom. The second doesn't hold for lists. -- David Menendez http://www.eyrie.org/~zednenem/

On 26 Jan 2005, at 08:41, Keean Schupke wrote:

I cannot find any reference to MonadPlus in category theory. At a guess I would say that it was the same as a Monad except the operators are id and co-product (or sum)... That would mean the 'laws' would be exactly the same as a Monad, just with (0,+) instead of (1,*)...

I don't know if the categorists have a word for it. It isn't "the same as a Monad except", it's rather "the same as a Monad and also...". Note that translating between the normal categorical point of view and the haskell one is something of a pain since programmers think with Kleisli arrows (computations). A MonadPlus is a Monad T with, in addition, the structure of a monoid on all types T a, satisfying the some conditions. I follow Wadler and use zero and ++ for the monoid. Unit conditions: If you apply a monadic computation (that is, Kleisli arrow) to the zero object you get zero, that there is a special zero computation (that is concretely \x -> zero) which gives you the zero object when you apply it to anything. Compatibility of ++ with computations: The first condition just says that if you apply a computation to the sum of two objects, that should be the same as applying the computation twice, once to each object, and adding the results. (m ++ n) >>= f == (m >>= f) ++ (n >>= f) The two slightly more subtle conditions observe that it is possible to 'lift' the monoid operation to Kleisli arrows, i.e. if you can add objects, then you can add computations (of the same type): (+++) : (a -> m b) -> (a -> m b) -> (a -> m b) \f g x -> f x ++ g x Then you require that if you first add two computations and apply them to a single object, you get the same result as applying the computations separately and adding the results.. m >>= (f +++ g) == (m >>= f) ++ (m >>= g) ----- If these are a common categorical notion then I'd expect them to be called 'additive monads' or something, but I can't immediately track down a reference. If you translate the notion back to the more standard categorical approach, using mu (join) and eta (return), it may be enlightening, but off hand I can't quite see what the rules look like. Jules

Jules Bean wrote:

Are there any interesting programming uses of MonadPlus apart from 'calculations returning multiple values'.. i.e. lists/sets/multisets/maybe?

Just a minor point ... You mention Maybe in the list above but I would like to wonder whether it is fully appropriate to associate it with "calculations returning multiple values". Depending on what you find interesting, I would like to mention *biased binary choice*. Try the left operand first, if it fails, try the second operand. For instance, this is a key idiom in strategic programming with Strafunski (and has been adopted from Stratego). All in all, this more like "try and catch" or "exception handling" rather than "calculations returning multiple values". Ralf -- Ralf Laemmel VU & CWI, Amsterdam, The Netherlands http://www.cs.vu.nl/~ralf/