I like the idea of a separate translator that understands how to make the obvious changes required by such minor improvements (remove/add definitions of return, remove/add imports of Applicative, etc), and having that applied by cabal when the code is built.

Then library authors could write normal code conforming to *one* release, instead of figuring out the clever import gymnastics or CPP required to code simultaneously against several almost-compatible interfaces (or forking).

Some meta data in a cabal file could hopefully be all you need to allow your code to be adjustible forward or backward a few dialects.

On 9 October 2015 5:05:43 am AEDT, Joachim Breitner <mail@joachim-breitner.de> wrote:
Hi,

Am Donnerstag, den 08.10.2015, 13:05 -0400 schrieb Richard Eisenberg:
 On Oct 8, 2015, at 9:55 AM, Ben Gamari <ben@smart-cactus.org> wrote:
  With a few changes to our treatment of warnings
 and some new pragmas (aimed at library authors), we can greatly
 reduce
 the impact that library interface changes have on users.
 
 My loose following of the interweaved threads has led me to this same 
 conclusion. Have you paid close enough attention to list exactly what 
 these changes should be? I have not. But I'd love to find a general 
 solution to the migration problem so that we can continue to tinker 
 with our beloved language without fear of
flames burning down the 
 house.

how willing are we to make the compiler smarter and more complicate to
make sure old code does what it originally meant to do, as long as it
is among the (large number close to 100)% common case?

For example, in this case (as was suggested in some trac ticket, I
believe), ignore a method definition for a method that
 * is no longer in the class and
 * where a normal function is in scope and
 * these are obvious equivalent
where obvious may mean various things, depending on our needs.

One could think this further: If the compiler sees a set of Applicative
and Monad instances for the same type in the same module, and it has
"return = something useful" and "pure = return", can’t it just do what
we expect everyone to do manually and change that to "pure = something
useful" and remove return?

In other words, can we replace pain and hassle
for a lot of people by
implementation work (and future maintenance cost) for one or a few
people?

Or will that lead to another hell where code does no longer mean what
it says?

Greetings,
Joachim