[Haskell-cafe] Support for library improvement
Richard A. O'Keefe
ok at cs.otago.ac.nz
Fri Oct 9 00:36:27 UTC 2015
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.
More information about the Haskell-Cafe