# In opposition of Functor as super-class of Monad

Iavor Diatchki iavor.diatchki at gmail.com
Wed Jan 5 21:54:02 CET 2011

```Hi,
indeed, this is called "ap" in Control.Monad.  So if we have an instance of
Monad, all that needs to be done to support the other instances is:

instance (SameContextAsTheMonadInstance) => Functor MyType where fmap =
liftM
instance (SameContextAsTheMonadInstance) => Applicative MyType where pure =
return; (<*>) = ap

Furthermore, this is only in the cases where we are defining the type from
scratch, and not using a library like monadLib or MTL, otherwise a simple
"deriving" is sufficient.

-Iavor

On Wed, Jan 5, 2011 at 12:29 PM, Tony Morris <tonymorris at gmail.com> wrote:

> On 06/01/11 04:58, Isaac Dupree wrote:
> > Tony, you're missing the point... Alexey isn't making a complete patch
> > to GHC/base libraries, just a hacky-looking demonstration.  Alexey is
> > saying that in a class hierarchy (such as if Functor => Monad were a
> > hierarchy, or for that matter "XFunctor"=>"XMonad" or Eq => Ord), it
> > is still possible to define the superclass functions (fmap) in terms
> > of the subclass functions (return and >>=) (such as writing a functor
> > instance in which "fmap f m = m >>= (return . f)").  This has always
> > been true in Haskell, it just might not have been obvious.
> >
> > _______________________________________________
> Oh right sorry. I thought a stronger point was being made.
>
> Then perhaps it's also worth pointing out that (<*>) can be written
> using (>>=) and return:
> f <*> a = f >>= \ff -> a >>= \aa -> return (ff aa)
>
> --
> Tony Morris
> http://tmorris.net/
>
>
>
> _______________________________________________