Allow the annotation of a library patch with an updater to old user code

[Gurkenglas]

This would solve the problem of legacy API.

The PvP fits neatly around it: The leftmost number would be used for version changes that are not annotated with an updater.

Example proposals that would be/would have been made trivial with this (suggest more?):

• Functor-Applicative-Monad

[hvr]

Example proposals that would be/would have been made trivial with this

• Functor-Applicative-Monad

Btw, see https://github.com/hvr/Hs2010To201x for what's involved for the AMP/MFP/MRP monad refactorings; but this is everything but trivial. The proof-of-concept also can't handle all cases except the simplest ones (and tbh, I'm not even sure it's possible to handle almost all cases).

[Gurkenglas]

Of course the library author wouldn't manually implement the updater, they'd just specify it in a way that GHC can then apply with a system like the rewrite rules one.

[sjakobi]

This is a proposal for a tool similar to gofix, right?

In that case this recent comment by ekmett seems to be relevant::

The amount of CPP running around in Haskell with any sort of long support
window makes 'go fix' tools quite shockingly difficult for us to get right.

[hvr]

The problem is also that it's not a well-formed (non-clever/creative) subset of CPP usage; if it were only e.g. simple #if MIN_VERSION_... at safe boundaries (such that they include a full declaration or some other reasonable AST sub-tree) it would be an easier (but still not trivial) to job to refactor automatically.

[Gurkenglas]

The updater would run after CPP, of course.