On 20/02/06, Iavor Diatchki <[EMAIL PROTECTED]> wrote: > Hello, > > On 2/20/06, John Meacham <[EMAIL PROTECTED]> wrote: > > I think the problem is that 'mzero' exists, the correct solution seems > > to be to get rid of the 'mzero' method of MonadPlus. Since haskell is > > lazy, all Monads have at least the zero of _|_ which can be overriden by > > 'fail' with a more suitable one. MonadPlus should be about extending > > monads with an additive operator, there is no need for another concept > > of zero and it seems to me that is the real issue. mzero can simply be > > defined as 'fail "mzero"'. > > In what sense is _|_ a 'zero'? > > -iavor
This ties in with an important point which I've been pushing lately, that bottom should not be used for expected failure. Expected failure should be explicit, and appropriate monads (not monads in general!) make this convenient. I am rather strongly of the opinion that fail should not be a method of the monad class, since it is so common that the only implementation one can give, even in perfectly reasonable monads, is 'error'. Bottom is acceptably used in sanity checks where if it occurs, the programmer must be at fault. However, due to the inconvenience of catching _|_ in IO, I really find that in the vast majority of cases, explicitly representing failure (the Maybe and Either String monads being common candidates) is much nicer when errors are to be expected and handled internally to the application. One thing which I found odd about the NotJustMaybe pattern is that not much is really gained apart from a small amount of convenience. Of course, you get to pass back that string which is sometimes an advantage over Maybe but Either String gives you that as well. It's rather easy to embed Either String, or Maybe into any suitable larger monad which would otherwise apply, and you get more information about what type of errors can be passed back. (Maybe of course just represents partiality, while the use of Either String explicitly tells you that the function is prepared to hand you some form of error string.) Further, if the inconvenience of doing that embedding is still too great, we have the typeclass MonadError to differentiate between monads with and without failure mechanisms -- perhaps it could be cleaned up a bit in a few ways, but I think the idea is right. - Cale _______________________________________________ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell