title: Boilerplate code in the definition of a monad
body: <p>Since the <a href="https://wiki.haskell.org/Functor-Applicative-Monad_Proposal" rel="nofollow noreferrer">Functor-Applicative-Monad Proposal</a>, Monads are a subclass of Applicative which in turn is a subclass of Functor. Mathematically speaking, this seems to be a sensible choice and I do not have any problems with that.</p>
  <p>However, what is irritating me is that one is required to write down the Functor and Applicative instances even if the corresponding laws for <code>fmap</code> and <code>pure</code> and <code>&lt;*&gt;</code> are fixed by the monad laws anyways. Indeed, in the above linked proposal, they write themselves: &quot;You can simply derive these instances from the Monad by adding the following code&quot;:</p>
  <pre><code>import Control.Applicative (Applicative(..))
  import Control.Monad       (liftM, ap)
  
  instance Functor m where
      fmap = liftM
  
  instance Applicative m where
      pure  = {- move the definition of `return` from the `Monad` instance here -}
      (&lt;*&gt;) = ap
  </code></pre>
  <p>and in most tutorials, you will simply see the equality <code>pure=return</code> and people then go on to define <code>return</code> in the Monad instance as before. Therefore, effectively, 10 lines of boilerplate code were added for everyone who simply wants to define a Monad instance.</p>
  <p>In mathematics, one usually also does not operate in this way. For example, when defining the composition laws for a certain ring, the reader is usually not explicitly reminded again that rings are special instances of abelian groups under addition which in turn are special instances of groups. This is clear by definition anyways.</p>
  <p>Thus my question is: Even though it is fine that Monads are a subclass of Applicative which in turn is a subclass of Functor, couldn't this just &quot;happen in the background&quot; in the sense that the compiler inserts the boilerplate code instead of the programmer?</p>