G'day Cale. Quoting Cale Gibbard <cgibbard@gmail.com>:
I personally feel that the inclusion of 'fail' in the Monad class is an ugly solution to the problem of pattern matching, and gives the incorrect impression that monads should have some builtin notion of failure.
So do I.
We ought to be using MonadZero when we want to express failure, but it's gone!
I agree!
What do people think of the following proposal?
I don't like it. My feeling is that do { p <- xs; return e } should behave identically (modulo the precise error message if the pattern match fails) to map (\p -> e) xs. Your proposal would make it into a map/filter hybrid. Speaking more practically, if a pattern match is technically refutable, but I, as the programmer, intend it never to fail, then I shouldn't need to use MonadZero. I don't like fail either, but I must admit that I like allowing refutable patterns.
Thus, refutable pattern matches occuring in a do-expression would force the expression to be typed explicitly with MonadZero. This is probably a good thing, as it forces one to think about the consequences of not properly dealing with a pattern match in any monad which doesn't explicitly allow for failure.
Surely this is no different from not properly dealing with a pattern match in a case statement?
Even if this translation of do-syntax isn't accepted, I still think that we should have a separate MonadZero.
I agree. I miss MonadZero.
I'd also like to see the current use of MonadPlus split into MonadElse (or MonadOr) and MonadPlus, [...]
I agree, but I think such a proposal shouldn't be considered in isolation from standardising some MTL-like library.
Lastly, it would be nice to have some standard name for the function: option :: (MonadPlus m) => [a] -> m a option = foldr (mplus . return) mzero which seems to come up quite a bit in my experience with nondet monads.
I liked Oleg's suggestion: "choose", since it's the realisation of the axiom of choice. Though possible "mchoose" might be more appropriate. Even more appropriate might be to rationalise some of these naming conventions. Cheers, Andrew Bromage