On 2005-01-23, Keean Schupke <[EMAIL PROTECTED]> wrote: > Aaron Denney wrote: > >>You can, but the "other one" turns it into a copy of the Maybe Monad, so >>the current one is more useful. >> >> > So what does this mean in terms of Ashley's question: > > But only some instances (such as []) satisfy this: > > (mplus a b) >>= c = mplus (a >>= c) (b >>= c) > > Other instances (IO, Maybe) satisfy this: > > mplus (return a) b = return a > > Does it mean that both fall within the acceptable definition of the > monad laws for MonadPlus?
I believe so, yes. > 1. |mzero >>= f == mzero| > 2. |m >>= (\x -> mzero) == mzero| > 3. |mzero `mplus` m == m| > 4. |m `mplus` mzero == m| > > So I guess I must have missed the point because the distinction > between say a monad on [] and Maybe for example seems to me to be > irrelevant to MonadPlus. The distinction comes down to mplus being the > same as skipError for Maybe and different for []. Right. But the point was that the behaviour of mplus gives different behaviour for the use of the class as a whole when used as a monad. Not, of course, when neither mzero or mplus is used, but it changes how they can be used. We could try to seperate the two behaviours above into two typeclasses to keep them the semantics as part of the type, but when we try, we find it doesn't really work well, as there's no operation (or value) defined in one but not the other, which makes it far less useful. We use typeclasses precisely to abstract away some parts while enforcing others. -- Aaron Denney -><- _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
