hs2010to201x's Introduction

Automatic H2010 to H201x Refactoring

Typeclass Refactoring

`Monad`-hierarchy

Haskell Report Definitions

Haskell 2010 defines only the Functor and Monad typeclasses:

class  Functor f  where
    fmap    :: (a -> b) -> f a -> f b

class  Monad m  where
    return  :: a -> m a

    (>>=)   :: m a -> (a -> m b) -> m b

    (>>)    :: m a -> m b -> m b
    m >> k  =  m >>= \_ -> k
    
    fail    :: String -> m a
    fail s  = error s

With Haskell 201x this evolves into

class  Functor f  where
    fmap    :: (a -> b) -> f a -> f b

class Functor f => Applicative f where
    -- | Lift a value.
    pure :: a -> f a

    -- | Sequential application.
    (<*>) :: f (a -> b) -> f a -> f b

    -- | Sequence actions, discarding the value of the first argument.
    (*>) :: f a -> f b -> f b
    (*>) = …

    -- | Sequence actions, discarding the value of the second argument.
    (<*) :: f a -> f b -> f a
    (<*) = …

class Applicative m => Monad m where
    -- | Monadic bind
    (>>=) :: forall a b. m a -> (a -> m b) -> m b

class Monad m => MonadFail m where
    -- | Invoked on pattern-failures in monadic binds
    fail :: String -> m a

-- Backward-compatible top-level alias bindings

(>>) :: Functor m => m a -> m b -> m b
(>>) = (*>)

return :: Applicative m => a -> m a
return = pure

GHC: Interim Haskell 2010 + `Applicative` definitions

There are multiple intermediate stages:

GHC 7.0 to 7.8: Haskell 2010 Functor/Monad class hierarchy + non-superclass Applicative
GHC 7.10: Haskell 201x Functor/Monad/Applicative class hierarchy (sans MonadFail) with legacy return/(>>)/fail
GHC 8.0 to 8.X: Haskell 201x Functor/Monad/Applicative/MonadFail class hierarchy with legacy return/(>>)/fail
GHC 8.X+2: Haskell 201x

Rewrite rules

Converting from plain Haskell2010 to Haskell201x is simple:

Create Functor instance if missing with fmap defined in terms of (>>=) and pure
Create Applicative instance and define (<*>) in terms of (>>=) and pure
Rewrite Monad(return) implementation into Applicative(pure) implementation
If exists, rewrite Monad((>>)) implementation into Applicative((*>)) implementation
If fail is defined, create MonadFail instance with that fail method implementation

TODO: Give rules based on AMP-migration-guide definitions

hs2010to201x's People

Contributors

Stargazers

Watchers

Forkers

alanz

hs2010to201x's Issues

Warn about possible performance issue (>>) and (*>)

In https://mail.haskell.org/pipermail/libraries/2015-November/026504.html @takano-akio suggests

I understand this, but perhaps there is a way to achieve this without
slowing down existing code. How about introducing a new warning
(enabled with -Wall) that is triggered when a type satisfies the
following 3 conditions?

The type has a Monad instance and an Applicative instance declared
in the same module, with the same set of constraints.

(*>) is not defined as (*>) = (>>). i.e. either it has a
non-trivial definition or its definition is left out.

(>>) is not defined as (>>) = (*>). i.e. either it has a
non-trivial definition or its definition is left out.

This way, people can be warned when (*>) and (>>) can share an
implementation but they don't.