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

[Edward Kmett]

On Tue, Jun 22, 2010 at 4:54 PM, Gregory Crosswhite <
gcross at phys.washington.edu> wrote:

>  There is no reason that your program couldn't link to multiple versions of
> the same package so that each library can access the version that it needs.
> In fact, GHC already does this, doesn't it?  For example, I use a mixture of
> libraries in my programs that link to QuickCheck 1 and QuickCheck 2, and
> this works just fine.
>

This works fine as long as no detail of the embedded library leaks into the
public API. QuickCheck is typically the least painful library to mix, since
you don't typically use the quickcheck properties from multiple quickcheck
versions drawn from other packages at runtime.


> The only problem I've had is with cabal, which when resolving dependencies
> seems to only be able to pick out one version of a package;  in some cases
> instead of running "cabal install A B" where A and B depended on different
> versions of the same package (QuickCheck) I had to instead separately run
> "cabal install A" and "cabal install B".  This isn't a big deal, but I could
> imagine cases where it could fail to automatically install a package
> entirely due to conflicting version requirements.  This, however, is not
> because there is an intrinsic problem with installing multiple versions of a
> library, but simply because cabal sometimes seems to get confused about what
> it needs to do.
>

cabal is the only mechanism that the vast majority of Haskell-users know how
to use these days. Resolving diamond dependencies safely relies on knowing
tha tthe use of different libraries is entirely internal to the library in
question -- a detail that is not currently exposed through the cabal file.
You can use PackageImports to try and hack around common package names at
least in GHC, but it then further confuses purpose and provenance.


> So in short, I see no problem with there being multiple versions of a
> package floating around, and to the extent that an implementation of
> something can't handle this it seems like this is arguably a bug in that
> implementation rather than a bug in the package system for allowing the
> possibility.
>

There are multiple potential implementation semantics that can be assigned
to a diamond dependency. The types could be incompatible. They could be
compatible, and the most recent version should be used by all (in case of
minor API changes). They could be somewhere in between.

I suppose where we differ is in how big of a concern we view 'just cabal
having a problem with it' is. All I can say is that every time there has
been a major API change where half the community hasn't moved, it has been a
practical problem. It become yet another implementation detail that every
subsequent developer has needed to consider, and providing support and
instances for both is impractical.

So while in theory, just bumping the major version number would be
sufficient, in practice, I think picking a new package name and namespace
would:

* fit more closely with the spirit of a ground-up redesign
* allow it to succeed or fail on its own merits
* avoid torturing new users with cabal install warnings they won't
understand
* allow libraries that want or need to be agnostic with respect to the
change the ability to provide instances for both libraries, providing a
smoother upgrade path for their users.

Which in the end, seems to be a net positive over:

* requiring folks to use one version of fgl entirely internally without
exposing it through their API or splinter their user base
* causing cabal to panic
* ultimately adding yet another hack to the hackage config which indicates
implied upper bounds on the stable version of the package, since the current
fgl is part of the haskell platform and the new design will not be stable
for some time

If fgl wasn't part of the haskell platform or the changes were less radical,
the balance of net good might go the other way.

-Edward Kmett
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20100623/774461a0/attachment.html