On 25 Jan 2005, at 11:49, Keean Schupke wrote:
Jules Bean wrote:
A monad T is a (endo)functor T : * -> * where * is the category of types, together with a multiplication mu and a unit eta.
So, * is the category of Types, and functions on type (which map values to values), and T is an endofunctor (mapping functions on type to functions on type).
T is an endofunctor (mapping functions on types to functions on types *and* types to types) : functors map not only morphisms but also objects.
How does this affect the IO monad though?
m >>= (\a -> mzero) === mzero
If we consider the state monad, surely the above makes no comment on what the final state should be, only the final value returned...
Or is MonadPlus not definable on State monads?
I don't know. The reason I don't know, is I can't actually find written down the laws that MonadPlus is 'supposed' to obey. I agree with the OP (ashley, IIRC) that mzero and the IO monad behave in a surprising way. I would think that the closest I could get to a 'sane' definition of MonadPlus for State Monads is something which for mzero goes into a 'special state' representing exception (with undefined for a value, I suppose), and for mplus tries the left branch, if that goes into the exception state then tries the right branch.
If it is then considering IO === ST RealWorld, would imply that the actions of the IO monad are not important as long as the final value returned is mzero?
Well, mzero isn't a return value in the IO monad, it's an exception. But yes, I agree with you that the (plausible) laws I have seen for MonadPlus seem to say that mzero should ignore the actions. But this in practice is not how IO behaves. Jules