
If I understood your post correctly, you said
- generalizing lookup to MonadPlus or Alternative or such classes are
not necessary
- use Maybe as usual, we should use adapters as we need
Conor, You have said this many times elsewhere, but unfortunatelly, I
heard it for the first time =) so please correct me if I'm wrong.
I thought generalizing lookup is good example for usage of the
MonadPlus as I read in RWH[1], but you said it's not necesarry.
Now, I understood there are two positions for such classes. One is
using generalizing for it, another is not.
So, I want to know that when such classes should be used from later position.
Heinrich suggested that is for overloading. But do any other usages are exist?
[1]: http://book.realworldhaskell.org/read/programming-with-monads.html#VCard.hs:...
Cheers
-nwn
On Tue, Sep 15, 2009 at 5:21 PM, Conor McBride
Hi
This topic comes up a lot, and this is what I usually say when it does. It's a thing I learned from James McKinna, many years ago...
Might I gently suggest that there is a much better, more natural way to abstract over every type-former which has some sort of return/pure-like thing and some sort of mzero/empty like thing? You could use the type-former which is inductively defined to be the least such thing, and as such has a canonical mapping to all the others, namely Maybe.
It's not necessarily a good idea to fix on Monad or MonadPlus as there are other choices. For example,
On 15 Sep 2009, at 07:14, Yusaku Hashimoto wrote:
I prefer Alternative to MonadPlus for explaining failure. It has better name and operator for failure and try-another.
import Control.Applicative
aLookup :: (Alternative f, Eq k) => k -> [(k,v)] -> f v aLookup key pairs = maybe empty pure $ lookup key pairs
there are notorious non-monadic instances for the above f (some formulations of parsing, in particular). So,
I understand that fail being in Monad is controversial, but my version of the function works in *all* monads.
this is a touch presumptuous. On the one hand, Brent is right when he says
It doesn't work in *all* monads -- it only works in monads which support a sensible notion of failure.
but he's perhaps excessive when he says
This is exactly what is captured by the MonadPlus constraint on my version of mLookup.
because it's not exact: it requires mplus as well as a sensible notion of failure. And yes, why should we insist on (>>=) when we just need a return and an mzero? Incidentally, I don't know where the MonadPlus instance
(IO, Maybe, [], ...) are already instances of MonadPlus.
of IO is coming from, but I want it caught and locked up now (in STM, for example) before it does any permanent damage.
Why not factor out the failure-prone operations from the business of interpreting failure in some failure-supporting context? Work concretely while you can (types stay shorter, error messages make more sense) then apply adapters
malt :: Alternative f => Maybe x -> f x malt = maybe empty pure
mop :: MonadPlus m => Maybe x -> m x mop = maybe mzero return
when you need to? This also reduces the risk of connecting an ambiguous supplier to an ambiguous consumer, (show . read) style.
The message clearly bears repeating. Inductive definition is a concrete form of abstraction. Don't be fooled by its appearance: Maybe is the most abstract choice here -- the classier options demand more structure than is needed and thus exclude use-cases.
I'll crawl back under my stone now.
All the best
Conor
_______________________________________________ Beginners mailing list Beginners@haskell.org http://www.haskell.org/mailman/listinfo/beginners