aelve / haskell-issues

An unofficial issue tracker for all things Haskell-related
18 stars 0 forks source link

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

Open Gurkenglas opened 7 years ago

Gurkenglas commented 7 years ago

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?):

hvr commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

The updater would run after CPP, of course.