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... 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