[Haskell-cafe] Rewriting a famous library and using the same name: pros and cons

Edward Kmett ekmett at gmail.com
Tue Jun 22 16:06:53 EDT 2010


The problem is that nothing breaks immediately.

Then someone else comes along and transitively depends on your package and
on another package, which depends on the newer version.

Your users wind up with strange conflicts like that if they are using Parsec
3 they can't use HTTP.

Or if they use fc-labels they can't use any library that internally uses
mtl, because fc-labels uses transformers. Or worse they want to use a
library that used fc-labels internally with another library that used mtl
internally.

It fragments the library base that you are able to use.

Version caps are not the answer.

-Edward Kmett


On Tue, Jun 8, 2010 at 2:21 PM, Gregory Crosswhite <
gcross at phys.washington.edu> wrote:

> Or you just put an upper bound on the versions of the fgl library that your
> program will build against, as you should be doing anyway, and then nothing
> breaks.
>
> Cheers,
> Greg
>
> On Jun 8, 2010, at 11:08 AM, Gene A wrote:
>
>
>
> On Tue, Jun 8, 2010 at 8:08 AM, Don Stewart <dons at galois.com> wrote:
>
>>
>> (... There have been a few cases of major API  / rewrites to famous old
>> packages causing problems, including:
>>
>>    * QuickCheck 1 vs 2
>>    * parsec 2 vs 3
>>    * OpenGL
>> ...)
>>
>
>
>> (...  * No additional breakages are introduced. ...)
>>
>
> Oh lord yes...  just call it fgl3  and leave the fgl package alone.
> This is a source based community here... so you take a package that
> has a dependency on another library and you go out and get that to cover
> the
> dependency and the API is not the same!!!  AND especially if that might be
> the
> only thing you will ever use that lib for ... and you have to stop and
> rewrite the
> original.. and as someone else said with maybe documentation of that API
> that
> is not maybe finished or...  NO ... At that point the person will probably
> just
> DISCARD the compile on the lib or program that had the dependency.. rather
> then put the effort in to learn an entire API that doesn't match up..
> BAD IDEA!!
>
> cheers,
> gene
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
>
>
> _______________________________________________
> 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/20100622/12a7b69e/attachment.html


More information about the Haskell-Cafe mailing list