Burning bridges

[Nicolas Trangez]

On Fri, 2013-05-24 at 09:30 +0200, Petr Pudlák wrote:
> Dne 24.5.2013 04:57, Bardur Arantsson napsal(a):
> > I'm a bit surprised I haven't seen anyone mention it, but the Go
> > community have a tool which can automate a lot of the tedium of API
> > transitions:
> >
> >     http://blog.golang.org/2011/04/introducing-gofix.html
> >
> > Maybe I'm missing something, but surely this kind of tool (a "hlint on
> > steriods", I guess) could be written for many of the breaking changes
> > that have been suggested in recent days on this list.
> >
> > Gofix specifically doesn't try to fix absolutely *everything*, but it
> > fixes all the trivial stuff which is extremely annoying, but
> > automatable, such as import lists, module/function renames, etc. (For a
> > recent example, see "catch".)
> >
> > Heck, one could even imagine building in a "--future" mode into such a
> > program to handle changes "one version ahead" during the deprecation
> > cycle (which I assume we're not getting rid of). It could, for example,
> > start issuing appropriate warnings for the Applicative => Monad
> > transition. (Which would mean that we wouldn't need ad-hoc modifications
> > to GHC to support such transitions.)
> >
> > AFAICT having such a tool in the Go ecosystem has been a huge boon, at
> > least while the language and APIs were developing and in the transition
> > from Go 1.0 to 1.1.
> >
> >
> 
> I'd also support the suggestion of making several changes at once, that 
> solve many recurring problems. For me it's easier to make one big 
> upgrade to my code once, than to make a small upgrade every now and then 
> if the language changes in small steps.
> 
> The idea of making an automated tool is really great, I was just 
> thinking about something similar. Some changes would be really trivial, 
> like adding "import Interlude". Some would be slightly more complex, 
> like refactoring Monad instances into Applicative+Monad, but I believe 
> it'd be very well possible.

This has been coined on haskell-cafe some time ago as well, see [1] and
[2].

Nicolas

[1] http://www.haskell.org/pipermail/haskell-cafe/2013-May/108086.html
[2] http://www.haskell.org/pipermail/haskell-cafe/2013-May/108087.html