Implement Functor => Applicative => Monad Hierarchy (aka AMP phase 3)

[gidyn]

The standard class hierarchy is a consequence of Haskell's historical development, rather than logic. I would therefore like to propose a reform of the Functor, Applicative, and Monad type classes. The new hierarchy is logical, eliminates many duplicate names from the standard type class definitions, and removes the need for boilerplate Monad -> Applicative instance declarations.

The proposal is detailed in ​the wiki, along with an example of a legacy module to provide some backwards-compatibility.

[gidyn]

Formally proposing this on the mailing lists, with a discussion deadline of 1 February.

[basvandijk]

Prepare GHC for the new monad hierarchy

[basvandijk]

Patch for base that implements the new monad hierarchy

[basvandijk]

Patch for happy that generates a Functor and Applicative instance for HappyIdentity

[basvandijk]

All my patches can also be pulled from my publicly available ghc repository:

darcs pull http://bifunctor.homelinux.net/~bas/ghc/
darcs pull http://bifunctor.homelinux.net/~bas/ghc/libraries/base
darcs pull http://bifunctor.homelinux.net/~bas/ghc/...

Also see the ​generated haddock documentation of the base library with the patches applied.

[gidyn]

Please note that the attached patches only implement the new Applicative => Monad hierarchy, but do not change any names (as proposed on the wiki page). The deprecation/renaming of redundant definitions may be proposed in a separate ticket.

[igloo]

Proposal tickets are no longer needed as part of the library submissions process. Instead, a normal ticket should be created once consensus has been achieved. Please see the ​process description for details.

[hvr]

Reusing this old AMP ticket so I don't have to create a new one to track AMP progress;

AMP phase 1 was covered by #8004, while this ticket is about phase 3 (actually implementing the change)

The AMP was implemented in a single monolithic commit, followed by AMP-related follow-up patches fixing up things as well as generalising some type signatures from Monad to Applicative:

• d94de87252d0fe2ae97341d186b03a2fbe136b04 ("Make Applicative a superclass of Monad")
• 65f887e1a0d864526f6a2609a3afc2c151c25e38 ("base: Add some notes about the default impl of (>>)")
• 6477b3dc058a92b825ef30d98797603b4a44a001 ("testsuite: AMPify ioprof.hs")
• 29e50da4c274eba0e444ce4b95294a76832908f2 ("testsuite: AMPify T3001-2")
• f636faa7b2b7fc1d0663f994ad08f365d39a746d ("Set default-impl of mapM/sequence methods to traverse/sequenceA")
• a07ce1654ac5b8033f2daf9270c6e182415b69ca ("Generalise Control.Monad.{when,unless,guard}")
• bf3329104c971c84ab178f3ded88254b9594f9cc ("Generalise guard for real this time")
• a1b539142d7853bc02c36f1b3e8d489a9864f0e9 ("testsuite: fix T5751 build failure (AMP)")
• b30b185e5c653dfed948d71ce2336be70be3b418 ("testsuite: fix T1735_Help/State.hs build failure (AMP)")
• abba3812e657a5267bba406d2c877c1cb5d978f9 ("Improve Applicative definitions")

[Herbert Valerio Riedel <hvr@…>]

In a741e69a230eb6d6e3373ad1fbe53c73b5f95077/ghc:

Provide default implementation of `Monad(return)`

This was dropped last-minute from d94de87252d0fe2ae97341d186b03a2fbe136b04
(re #4834) together with the default implementation for `(>>)`
(see 65f887e1a0d864526f6a2609a3afc2c151c25e38 for explanation).

However, the risk of accidental mutually recursive definitions of
`return`/`pure` is rather low as unlike with the `(>>) = (*>)` default,
any cyclic definitions would necessarily wind up being new ones, rather
than changing the semantics for old operations and introducing bottoms.

On the other hand, not having the default method implementation in place
in GHC 7.10 would complicate/delay any future attempt to clean-up the
`Monad`-class.

This finally allows (for `base >= 4.8`) to define a F/A/M instance-chain
with the following minimal definitions (while ignoring that `return` is
still a class-method in `Monad`)

  instance Functor M where
    fmap  = ...

  instance Applicative M where
    pure  = ...
    (<*>) = ...

  instance Monad M where
    (>>=) = ...

Reviewed By: ekmett, austin

Differential Revision: https://phabricator.haskell.org/D647

[hvr]

Replying to Herbert Valerio Riedel <hvr@…>:

In a741e69a230eb6d6e3373ad1fbe53c73b5f95077/ghc:

...also merged to ghc-7.10 via 262f7a85bb1d40770245b990527eb0bee7c20195