#8004: Applicative/Monad proposal related warnings (AMP phase 1) -------------------------------------+------------------------------------- Reporter: quchen | Owner: quchen Type: feature request | Status: closed Priority: high | Milestone: 7.8.1 Component: Compiler | Version: 7.6.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #4834 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ekmett): Replying to [comment:23 songzh]:

I am so curious that I want to ask for the case "You have an instance of Monad, but not Applicative" why cann't we add default implementation to Applicative typeclass? {{{ class Functor f => Applicative f where pure :: a -> f a default pure :: Monad f => a -> f a pure = return

At least in the case of `pure` and `return` we have the default definition of `return` in terms of `pure`. That flow the 'right' way through the class hierarchy and doesn't require an extension. Doing both that and this yields a cycle with no way to detect it through `MINIMAL` pragmas and the like, which can't straddle two classes.

(<*>) :: f (a -> b) -> f a -> f b default (<*>) :: Monad f => f (a -> b) -> f a -> f b (<*>) f a = ap }}}

This one could be done. It'd require a willingness to have an attempt to implement `Applicative` that doesn't supply a `(<*>)` to be a compile error rather than a warning, however. (A state that can arise as you write incrementally.) It is a fairly minor concern, but given the difficulty of pushing through Prelude related changes one that __may__ be a sufficient blocker. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8004#comment:24 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler