Opened 5 years ago

Closed 6 months ago

#4834 closed task (fixed)

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

Reported by: gidyn Owned by:
Priority: high Milestone: 7.10.1
Component: libraries/base Version: 7.0.1
Keywords: report-impact Cc: ekmett, thoughtpolice, hvr
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: None/Unknown Test Case:
Blocked By: Blocking:
Related Tickets: #8004 Differential Revisions: Phab:D13

Description

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.

Attachments (3)

ghc_new_monad_hierarchy.dpatch (110.0 KB) - added by basvandijk 5 years ago.
Prepare GHC for the new monad hierarchy
base_new_monad_hierarchy.dpatch (81.4 KB) - added by basvandijk 5 years ago.
Patch for base that implements the new monad hierarchy
functor_and_applicative_instance_HappyIdentity.dpatch (1.7 KB) - added by basvandijk 5 years ago.
Patch for happy that generates a Functor and Applicative instance for HappyIdentity

Download all attachments as: .zip

Change History (15)

comment:1 Changed 5 years ago by gidyn

  • Cc gideon@… added

comment:2 Changed 5 years ago by gidyn

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

Changed 5 years ago by basvandijk

Prepare GHC for the new monad hierarchy

Changed 5 years ago by basvandijk

Patch for base that implements the new monad hierarchy

Changed 5 years ago by basvandijk

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

comment:3 Changed 5 years ago by 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.

comment:4 Changed 5 years ago by 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.

comment:5 Changed 5 years ago by igloo

  • Milestone set to Not GHC

comment:6 Changed 4 years ago by igloo

  • Resolution set to invalid
  • Status changed from new to closed

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.

comment:7 Changed 2 years ago by gidyn

  • Cc gideon@… removed

comment:8 Changed 6 months ago by hvr

  • Cc ekmett thoughtpolice hvr added
  • Differential Revisions set to Phab:D13
  • Keywords report-impact added
  • Milestone changed from Not GHC to 7.10.1
  • Priority changed from normal to high
  • Resolution invalid deleted
  • Status changed from closed to new
  • Type changed from proposal to task

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:

comment:9 Changed 6 months ago by hvr

  • Summary changed from New Functor => Applicative => Monad Hierarchy to Implement Functor => Applicative => Monad Hierarchy (aka AMP phase 3)

comment:10 follow-up: Changed 6 months ago by 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

comment:12 Changed 6 months ago by hvr

  • Resolution set to fixed
  • Status changed from new to closed
Note: See TracTickets for help on using tickets.