# Functor-Applicative-Monad Proposal

From HaskellWiki

Haskell calls a couple of historical accidents its own. While some of them, such as the "number classes" hierarchy, can be justified by pragmatism or lack of a strictly better suggestion, there is one thing that stands out as, well, not that: Applicative not being a superclass of Monad.

The topic has been discussed multiple times in the past (cf. link section at the bottom). **This article was updated to describe the current, and very likely to succeed, Haskell 2014 Applicative => Monad proposal (AMP)**.

## Pragmatic and short version

The following is a list of things you may have to change in your code so the AMP doesn't break it.

- Add Applicative/Functor instances for all your Monads. If you don't care about efficiency, you can simply derive these instances from the Monad by adding the following code:

```
-- Monad m
import Control.Monad (liftM, ap)
import Control.Applicative (Applicative(..))
instance Functor m where
fmap = liftM
instance Applicative m where
pure = return
(<*>) = ap
```

- Add an Alternative instance for all instances of MonadZero. This can again be done easily using

```
-- MonadZero m
import Control.Monad (mzero, mplus)
import Control.Applicative (Alternative(..))
instance Alternative m where
(<|>) = mplus
empty = mzero
```

- Change your API to not define functions named
`<*>`

,`join`

or`pure`

.

## Detailed description

Main text of the Haskell 2014 AMP

Mailing list discussion of the proposal

## Previous proposals

- From early 2011: GHC ticket – Makes Applicative into a superclass of Monad, but does not deprecate any existing names
- See [1] for the associated discussion.

- The Other Prelude