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

Sebastian Fischer sebf at informatik.uni-kiel.de
Sun May 2 04:23:16 EDT 2010


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

     instance Functor m where
       fmap = liftM

     instance Applicative m where
       pure = return
       (<*>) = ap

     instance Alternative m where
       empty = mzero
       (<|>) = mplus

The laws required by MonadPlus imply the laws required by theses  
instances.

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

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

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.

Sebastian


-- 
Underestimating the novelty of the future is a time-honored tradition.
(D.G.)





More information about the Haskell-Cafe mailing list