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

[Edward Kmett]

On Wed, Jun 23, 2010 at 2:57 PM, Gregory Crosswhite <
gcross at phys.washington.edu> wrote:

>  On 6/23/10 2:13 PM, Edward Kmett wrote:
>
> 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.
>
>
> Yes, but if details of the package you are using are "leaking" out into the
> interface then you will have the same kind of problems whenever that package
> conflicts with any other package, regardless of whether the conflict is with
> a package of the same name.  For example, for a while there was a conflict
> between mtl and transformers because they shared a package name, and the
> fact that the two packages had different names didn't make the problem any
> better.
>

Yes, and that problem still isn't resolved in another since, since they
share the same module names, but as of yet, still provide an incompatible
API. I can't (yet) provide 'RightSemiNearRing' instances that work with both
the monad transformers from transformers and mtl without deep mojo. The
resolution there seems to be to bring transformers and mtl into close enough
alignment that we'll be able to finally release a version of the mtl that
just imports transformers and monads-fd, and provide a set of guidelines
about the fact that in the switch to the next major version of mtl, the
non-transformer versions of the monad-transformer stack are just type
aliases. In that case the APIs are close enough that with a few breaking
changes to existing users on each side, the APIs can be reconciled and the
community unfractured. That said, we've had this plan waiting in the wings
for months. ;)

But cabal can see with exactly which packages each of the dependencies
> requires, right?  So what is stopping it from just walking through the
> dependencies and constructing the dependency graph?  It should have all of
> the information it needs to do this.
>

This becomes somewhat tricky. You can do this more or less with data types
and classes, but with instances it is less clear how to do so. Instances
(necessarily) kind of silently infect your public interface, and so this
form of reasoning is at best global, not local. There has been some chatter
about splitting up build dependencies into internal and external
dependencies, although I don't know how serious it was, but that would be a
move in this direction.

To the extent that the full information that cabal needs exists and yet it
> is not capable of recognizing this, I would view this as a bug in cabal that
> we should fix, rather than deciding just to live with this bug and limiting
> ourselves to a subset of the package dependency functionality.
>

Regardless, it is unlikely to be fixed before Ivan goes to release his shiny
new type-family-driven FGL. =)

>   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.
>
>
> Yes, but again this will happen whenever you use two packages that
> conflict, regardless of whether they just happen to have the same name or
> not, as it did for a while with mtl and transformers.  Renaming fgl to
> newfgl won't actually make this situation any better.
>
[...]
> If we really are worried so much about these kinds of conflicts, then the
> real solution is to make sure that none of the modules exported by the new
> package share the same name as the modules in the old package.  And if one
> is going to do that anyway, then from the perspective of resolving conflicts
> there isn't any additional benefit to also renaming the package.
>
> Actually, once you've given them different module names keeping the same
package name _is_ an impediment. Because with different package names you
could import both and provide instances for both, say, fgl's Graph, and for
Ivan's very different type-family driven Graph, but you needlessly sacrifice
that upgrade path for your users if you force both packages to have the same
name.

Another very different consideration is that Erwig's old fgl is likely not
going away any time soon. As far as I can tell nothing in the Haskell
platform currently exploits type families and fgl is already in the
platform. Getting the new library into the platform would take quite a
while, even if it were available fully formed, debugged, and had an
installed user base today.

One much weaker consideration is that out of the 23+ direct dependencies on
fgl, fully half of them don't bother to specify an upper bound on the fgl
version and would break immediately. That said, those packages are out of
compliance with package versioning policy. =)

I agree with your point that perhaps cabal should be fixed to support
explicit or implicit handling of internal dependencies. I just think that
the practicalities in this situation point to fixing the problem with the
tools in the room, rather than waving our hands and making it Duncan's
problem. ;)

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