[Haskell-cafe] MonadPlus or Alternative or ...?

Sean Leather leather at cs.uu.nl
Sun May 2 05:10:53 EDT 2010


On Sun, May 2, 2010 at 10:23, Sebastian Fischer wrote:

>
> On May 2, 2010, at 1:11 AM, Sean Leather wrote:
>
>  I want to generalize a set of functions from lists to some functor type.
>> [...] Should I choose MonadPlus and use these? [...] Or should I choose
>> Alternative and use these? [...]
>>
>
> There are some types that can be an instance of Alternative but not of
> MonadPlus (because they are not a monad but an applicative functor). Hence,
> if you choose Alternative, then your functions are more generally
> applicable.


Right. Point for Alternative.

In practice, there may be instances of MonadPlus for wich their authors
> chose not to provide an Alternative instance and your functions then could
> not be applied to those types. But every MonadPlus instance `m` can be made
> an Alternative instance by declaring [...]
>

Or by using WrappedMonad I suppose.

That makes me wonder. Should there be Applicative and Alternative instances
of ReadP, ReadPrec, and P (whatever that is)? There are MonoidPlus instances
[1].

[1]
http://haskell.org/ghc/docs/6.12.1/html/libraries/base-4.2.0.0/Control-Monad.html#t%3AMonadPlus

 Or should I make my own class?
>>
>
> Then, there obviously won't be any instances for existing types other than
> your own (which might be a good or bad thing). You may want to do this, if
> you don't want to require either (>>=) or (<*>), which may not be supported
> for reasonable instances of your own class.


I don't really want to do this option, because it increases the
understanding overhead needlessly, I think. Everything else that is provided
by Applicative/Monad doesn't matter. I require only the three operations
above and do not disallow extra operations.


>  Or is there another option?
>>
>
> If you have functions that do not need return/pure you can also use a
> Monoid constraint on those functions and replace empty/mzero with mempty and
> <|>/mplus with mappend. Again, those functions share the same laws.
>

Yeah, I first started with Monoid, but I've come to the conclusion that I
need a container with return/pure.

Ideally, every MonadPlus instance would also be an Alternative instance and
> every Alternative instance would be an instance of Monoid. You may find it
> unfortunate that there are so many operations for the same thing but until
> the (Applicative/Monad) class hierarchy is refactored, we have to live with
> it.
>

I run into this kind of situation often. I would really like to see a better
division of operations between classes.

Thanks for the response, Sebastian!

Sean
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20100502/a5b8d411/attachment-0001.html


More information about the Haskell-Cafe mailing list