Re: [Haskell-cafe] Support for library improvement

Hi, Am Donnerstag, den 08.10.2015, 13:05 -0400 schrieb Richard Eisenberg:

On Oct 8, 2015, at 9:55 AM, Ben Gamari 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 -- Joachim “nomeata” Breitner mail@joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nomeata@joachim-breitner.de • GPG-Key: 0xF0FBF51F Debian Developer: nomeata@debian.org