[Haskell-cafe] Support for library improvement

[Richard A. O'Keefe]

On 9/10/2015, at 7:05 am, Joachim Breitner <mail at joachim-breitner.de> wrote:

> 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.
> ...
> Or will that lead to another hell where code does no longer mean what
> it says?

One help for avoiding that hell is for the compiler never to
deviate from the apparent semantics of the code without SHOUTING
about what it's doing.

There is also a big difference between the compiler adapting code
written for an old interface and tampering with code written for
a new interface, even if both involve the same actions on the
compiler's part.  The former may be helpful, the latter not.

I have long felt that version and dependency information should
be in a source file.  Arguably, the various language pragmas
sort of do that for *language* aspects.  When the compiler *knows*
what language version a module was written for and which library
versions, there are many possibilities:
 - refuse to compile code that's too old
 - quietly compile the code under the old rules
 - noisily compile the code under the old rules
 - quietly adapt the code to the new rules
 - noisily adapt the code to the new rules

Speaking only for myself, dealing with the change in my own code
is not going to be a big deal, because it affects the monads I
*define*, not the monads I *use*.  The main thing I need is very
clear warning messages from the compiler.