Language Change Management (was: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving `return` out of `Monad`)

[Phil Ruffwind]

Having so many #ifdefs isn't by itself a major problem.  Yes, it does
introduce a small increase in compilation time and the size of the
codebase.  The real cost is the developer time: every developer has to
come up with these these #ifdef clauses from scratch for every change
that gets made, tailored to their specific code.  As more and more get
added, it becomes more and more of a confusing mess.

It makes me wonder if this can be automated somehow.  It would be nice
to have a mechanism to alleviate this cost so that most developers
downstream (provided that the code was written in a reasonable manner)
only need to make a minimal effort to keep up, while still being able
to write code that works for a reasonably large range of GHC versions.
The burden of breaking changes right now is on the downstream
developers, but perhaps there could be a way to shift most of that
upstream to avoid this large duplication of effort.

Haskell should be allowed to evolve, but there also needs to be a
counterweight mechanism that provides stability in the face of
constant changes.  It would be something similar in spirit to
base-compat, but I don't think a library package alone is powerful
enough to solve the problem: a missing 'return' for example is not
something a library can just patch in.

I don't have any preference for "lots of small changes" vs "one big
change": in the former, there is a lot of overhead needed to keep
track of and fix these small changes; in the latter, there is a risk
of introducing a rift that fragments the community (cf Python 2 vs 3).
Maybe something in-between would be the best.