[Haskell-cafe] Support for library improvement

[Ben]

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 at 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 at 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
>
>-- 
>Joachim “nomeata” Breitner
>  mail at joachim-breitner.de • http://www.joachim-breitner.de/
>  Jabber: nomeata at joachim-breitner.de  • GPG-Key: 0xF0FBF51F
>  Debian Developer: nomeata at debian.org
>
>
>
>------------------------------------------------------------------------
>
>_______________________________________________
>Haskell-Cafe mailing list
>Haskell-Cafe at haskell.org
>http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151009/a307b1c8/attachment.html>