On Tue, Jun 22, 2010 at 4:54 PM, Gregory Crosswhite <span dir="ltr"><<a href="mailto:gcross@phys.washington.edu">gcross@phys.washington.edu</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div text="#000000" bgcolor="#ffffff">
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.<br></div></blockquote><div><br>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.<br>
<br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div text="#000000" bgcolor="#ffffff">
<br>
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.<br></div></blockquote><div><br>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.<br>
</div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div text="#000000" bgcolor="#ffffff">
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.<br></div></blockquote><div><br>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.<br>
<br> 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.<br>
<br>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:<br><br>* fit more closely with the spirit of a ground-up redesign<br>
* allow it to succeed or fail on its own merits<br>* avoid torturing new users with cabal install warnings they won't understand<br>* 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.<br>
<br>Which in the end, seems to be a net positive over:<br><br>* requiring folks to use one version of fgl entirely internally without exposing it through their API or splinter their user base<br>* causing cabal to panic<br>
* 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<br>
<br>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.<br><br>-Edward Kmett<br></div></div>