<html><head></head><body>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.<br>
<br>
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).<br>
<br>
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.<br><br><div class="gmail_quote">On 9 October 2015 5:05:43 am AEDT, Joachim Breitner <mail@joachim-breitner.de> wrote:<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<pre class="k9mail">Hi,<br /><br />Am Donnerstag, den 08.10.2015, 13:05 -0400 schrieb Richard Eisenberg:<br /><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #729fcf; padding-left: 1ex;"> On Oct 8, 2015, at 9:55 AM, Ben Gamari <ben@smart-cactus.org> wrote:<br /><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #ad7fa8; padding-left: 1ex;"> With a few changes to our treatment of warnings<br /> and some new pragmas (aimed at library authors), we can greatly<br /> reduce<br /> the impact that library interface changes have on users.<br /></blockquote> <br /> My loose following of the interweaved threads has led me to this same <br /> conclusion. Have you paid close enough attention to list exactly what <br /> these changes should be? I have not. But I'd love to find a general <br /> solution to the migration problem so that we can continue to tinker <br /> with our beloved language without fear of
flames burning down the <br /> house.<br /></blockquote><br />how willing are we to make the compiler smarter and more complicate to<br />make sure old code does what it originally meant to do, as long as it<br />is among the (large number close to 100)% common case?<br /><br />For example, in this case (as was suggested in some trac ticket, I<br />believe), ignore a method definition for a method that<br /> * is no longer in the class and<br /> * where a normal function is in scope and<br /> * these are obvious equivalent<br />where obvious may mean various things, depending on our needs.<br /><br />One could think this further: If the compiler sees a set of Applicative<br />and Monad instances for the same type in the same module, and it has<br />"return = something useful" and "pure = return", can’t it just do what<br />we expect everyone to do manually and change that to "pure = something<br />useful" and remove return?<br /><br />In other words, can we replace pain and hassle
for a lot of people by<br />implementation work (and future maintenance cost) for one or a few<br />people?<br /><br />Or will that lead to another hell where code does no longer mean what<br />it says?<br /><br />Greetings,<br />Joachim<br /></pre></blockquote></div></body></html>