On 9/10/2015, at 7:05 am, Joachim Breitner
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.