[GHC] #10071: Implement warnings for class-method overriding

9 Feb 2015

      #10071: Implement warnings for class-method overriding
-------------------------------------+-------------------------------------
              Reporter:  hvr         |             Owner:
                  Type:  feature     |            Status:  new
  request                            |         Milestone:  7.12.1
              Priority:  normal      |           Version:  7.8.4
             Component:  Compiler    |  Operating System:  Unknown/Multiple
              Keywords:  AMP         |   Type of failure:  None/Unknown
          Architecture:              |        Blocked By:
  Unknown/Multiple                   |   Related Tickets:  #8004, #4384
             Test Case:              |
              Blocking:              |
Differential Revisions:              |
-------------------------------------+-------------------------------------
 This would aid long-term transitions like phasing out `Monad(return)` (in
 the spirit of #4834):

 With the AMP, `Monad(return)` being a class method becomes an historic
 artifact. The ideal long-term situation would rather be to have `return`
 become a top-level definition (i.e. outside the `Monad`-class),
 generalised to `Applicative` just aliasing `Applicative(pure)`, i.e.

 {{{#!hs
 return :: Applicative f => a -> f a
 return = pure
 }}}

 This may be beneficial for things like ApplicativeDo which otherwise would
 require a `return` to be handled is if it was `pure` in order to weaken
 the type-constraint in an `do`-expression like e.g.

 {{{#!hs
 do { x <- f; return (fst x) }
 }}}

 Right now, we can attach a `DEPRECATE`-pragma to the `return`-class-
 method. That however would trigger warnings on ''all'' uses of `return`,
 rather than only when using `return` in a context that requires it to be a
 class-method (like overriding `return` in instance definitions, or
 importing/exporting it via the explicit `Monad(return)`-syntax)

 Instead we need a way to warn about such uses of `return` which assume it
 to be a class-method, in order to phase out such uses.

 NB: This will probably require additional discussions, but we shouldn't
 wait too long, if we want to integrate the AMP into a future Haskell
 Report (for which we should try to clean up historic warts such as
 `Monad(return)` if feasable).

--
Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10071
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler