[Haskell-beginners] Maybe, Either

[Yusaku Hashimoto]

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:lookupM

Cheers
-nwn

On Tue, Sep 15, 2009 at 5:21 PM, Conor McBride
<conor at strictlypositive.org> wrote:
> 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 at haskell.org
> http://www.haskell.org/mailman/listinfo/beginners
>