Changes between Version 9 and Version 10 of Design/DeprecationMechanisms/TypeClassMethods


Ignore:
Timestamp:
Sep 30, 2015 1:04:09 PM (4 years ago)
Author:
hvr
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • Design/DeprecationMechanisms/TypeClassMethods

    v9 v10  
    117117This would aid long-term transitions like phasing out class-methods, such as e.g. `Monad(return)` in the spirit of #4834:
    118118
    119 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)`. Moreover, the MonadFail proposal would have the `fail` method move to a new `MonadFail` class. I.e.
     119With the AMP, `Monad(return)` and `Monad((>>))` 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)`. Moreover, the MonadFail proposal would have the `fail` method move to a new `MonadFail` class. I.e.
    120120
    121121{{{#!hs
     
    136136class Applicative m => Monad m where
    137137  (>>=)  :: m a -> (a -> m b) -> m b
    138   (>>)   :: m a -> m b -> m b
    139138
    140139class Monad m => MonadFail where
     
    144143return :: Applicative f => a -> f a
    145144return = pure
     145
     146-- legacy synonym generalised to Applicative
     147(>>) :: Applicative f => f a -> f b -> f b
     148(>>) = (*>)
    146149}}}
    147150