[Haskell-cafe] Backward compatibility

[Michael Sloan]

Dependency breakage is certainly an unavoidable problem.  However, I think
Haskell is also in a much better position for having a technical solution
to the frustration of breakages.

Barring issues with changing datatypes / class instances, we can already
express many of the API changes you'd want to make to some library [1].
 Now, no one actually does what this proposal suggests - it's a lot of
work, and it doesn't work in general.  However, the fact that Haskell makes
something like this seem reasonable is heartening.

Of course, even if we had good tools that automatically refactored code to
use new APIs, it wouldn't be possible for any non-superficial changes.
 Even so, if a good enough refactoring tool existed, and it was popular
with both authors and users, a lot of the annoyance of dependency breakages
could be removed.

-Michael

[1]
http://haskellwiki.gitit.net/The%20Monad.Reader/Issue2/EternalCompatibilityInTheory



On Fri, May 3, 2013 at 2:04 AM, Ertugrul Söylemez <es at ertes.de> wrote:

> Raphael Gaschignard <dasuraga at gmail.com> wrote:
>
> > I'm pretty sure most of us have experienced some issue with
> > dependencies breaking , and its probably the most frustrating problem
> > we can have have in any language. It's hard not to take this all a bit
> > personally. Maybe if we think more about how to solve this (getting
> > people to maintain their stuff, for example) we can make the world a
> > better place instead of bickering about issues that are more or less
> > language-agnostic really.
>
> The problem can't be solved technically.  It's a human problem after all
> and it's amplified by the experimentalism in this community.  I think
> the best we can do is to acknowledge its existence, which places us way
> ahead of mainstream programming communities.
>
> We don't pretend that type X in lib-0.1.0 is the same as type X in
> lib-0.2.0.  What we need to work on is the ability to actually combine
> multiple versions of the same package conveniently, i.e. we shouldn't
> view this combination as an error.
>
>
> Greets,
> Ertugrul
>
> --
> Not to be or to be and (not to be or to be and (not to be or to be and
> (not to be or to be and ... that is the list monad.
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20130503/019b9bc2/attachment.htm>