#10071: Implement deprecation-warnings for class-methods to non-method transitions -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.8.4 Resolution: | Keywords: AMP Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: #8004, #4384 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Old description:
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).
New description: == What? Implement a `DEPRECATED`-variant to be attached to method declarations (in `class`-definitions) with default implementations that triggers warnings when 1. When an `instance` overrides the default implementation of that method, and/or 2. when such a deprecated method is explicitly im/(re)exported via `Class(method)`-syntax. But not when 1. imported as e.g. `import Mod1 (Class, method)` (which doesn't require `method` to be a method of `Class`), nor when 2. merely referring to `method` in an expression (as that doesn't require `method` to be a method either). Syntax suggestion: {{{ class C a where foo :: a bar :: a -> a bar x = x doo :: a -- this is the new syntax {-# DEPRECATED C(bar) "'bar' is going to become a non-method soon, please avoid referring to it as a method" #-} -- this works already now {-# DEPRECATED foo "'foo' is obsolete and going away soon, please use 'doo' instead" #-} }}} == Why? This would aid long-term transitions like phasing out class-methods, such as e.g. `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 `DEPRECATED`-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). -- Comment (by hvr): I hope this makes it more clear what I'm proposing. When I started writing the ticket I wasn't sure if I wanted a general facility, or something more adhoc for the specific AMP use-case, and so ended up with the incomplete description... -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10071#comment:2 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler