# Functor-Applicative-Monad Proposal

### From HaskellWiki

(Difference between revisions)

Lambda Fairy (Talk | contribs) (Add more things!) |
(Updated for AMP 2014) |

## Revision as of 12:58, 17 June 2013

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

## 1 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 ,<*>orjoinpure

## 2 Detailed description

Main text of the Haskell 2014 AMP

Mailing list discussion of the proposal

## 3 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