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