MRP Summary & revised MRP 2ed

Herbert Valerio Riedel hvriedel at gmail.com
Thu Nov 5 22:31:12 UTC 2015


Hi,

On 2015-11-05 at 15:53:39 +0100, Greg Weber wrote:
> Thanks for the clear revisions! It is unclear from the proposal how well
> the automatic re-factoring tool is expected to work.

Currently, Hs2010To201x does the following few things:

When a `Monad` instance definition is detected in a module,

 - if needed, define respective `Functor` instance (AMP)
 - if needed, define respective `Applicative` instance (AMP)
 - if needed, refactor return/pure definitions into canonical form (MRP)

This works fairly well for most common `Monad` instances. I ran it on
Cabal's code-base (for which only the MRP refactoring was relevant), and
the result looked very promising:

  https://gist.github.com/hvr/cd35fbcff9be6f3cb2a9


However, the major obstacle so far is CPP, which generally causes
problems with other tooling as well, and in particular /can/ confuse
ghc-exactprint.

Another source of problems are orphan-instances (specifically when the
`Applicative` instance is defined in a different module from the module
where the `Monad` instance is defined) as the tool currently operates on
single modules at a time.

Finally, the less frequent cases of nested Monads which require to
construct proper instance constraints for `Functor`/`Applicatives`
instances are not handled adequately yet. Examples are
`instance (Monad m) => Monad (ListT m)` or
`instance (Monad m) => Monad (StateT s m)`.


--HVR


More information about the Libraries mailing list