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
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe