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