<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
On 6/23/10 3:29 PM, Edward Kmett wrote:
<blockquote
cite="mid:AANLkTilBPTVJ1iQOJtZvy_jKIkE4SZHXlVKGSJNejxZI@mail.gmail.com"
type="cite">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. ;)<br>
</blockquote>
<br>
Oh, cool, so that's the plan? Grr, if I had fewer projects I would
volunteer to help out with this. :-)<br>
<br>
<blockquote
cite="mid:AANLkTilBPTVJ1iQOJtZvy_jKIkE4SZHXlVKGSJNejxZI@mail.gmail.com"
type="cite">
<div class="gmail_quote">
<div class="im"><br>
</div>
<blockquote class="gmail_quote"
style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div bgcolor="#ffffff" text="#000000">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.<br>
</div>
</blockquote>
<div><br>
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.<br>
</div>
</div>
</blockquote>
<br>
But does cabal even need to do an analysis that is that sophisticated?
All it needs to see are the package dependencies in order to note that,
"Oh, this package requires version X, and this package requires version
Y, so therefore I need to install both!" rather than saying, "Hold on,
these two packages require *different versions* of the same package? I
give up!"<br>
<br>
And conflicts between instances and things need to be taken care of
before the package can even be built, let alone uploaded to Hackage.
So while I agree that these are problems, they are not really cabal's
problem to worry about since by the time cabal has been brought into
the picture they must have already been resolved.<br>
<br>
<blockquote
cite="mid:AANLkTilBPTVJ1iQOJtZvy_jKIkE4SZHXlVKGSJNejxZI@mail.gmail.com"
type="cite">
<div class="gmail_quote">
<blockquote class="gmail_quote"
style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div bgcolor="#ffffff" text="#000000">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.<br>
</div>
</blockquote>
<div><br>
Regardless, it is unlikely to be fixed before Ivan goes to release his
shiny new type-family-driven FGL. =)<br>
</div>
</div>
</blockquote>
<br>
Fair point. :-)<br>
<br>
<blockquote
cite="mid:AANLkTilBPTVJ1iQOJtZvy_jKIkE4SZHXlVKGSJNejxZI@mail.gmail.com"
type="cite">
<div class="gmail_quote">
<blockquote class="gmail_quote"
style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div>
<div class="im">
<blockquote type="cite">
<div class="gmail_quote">
<blockquote class="gmail_quote"
style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; 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>
</div>
</div>
</blockquote>
<br>
</div>
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. <br>
</div>
</blockquote>
<blockquote class="gmail_quote"
style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div> [...]<br>
<div style="text-align: left;">
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.<br>
</div>
<br>
</div>
</blockquote>
<div>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. <br>
</div>
</div>
</blockquote>
<br>
Okay, so the assumption is that although dependencies could use
different versions of a package with the same name, when you yourself
use a package you can only use one particular version of the package.
Given this assumption I see your point, though perhaps it would be a
good idea to allow package imports to also allow you to specify the
major version number of the package you can import modules from two
different major versions of a package.<br>
<blockquote
cite="mid:AANLkTilBPTVJ1iQOJtZvy_jKIkE4SZHXlVKGSJNejxZI@mail.gmail.com"
type="cite">
<div class="gmail_quote">
<div><br>
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. <br>
</div>
</div>
</blockquote>
Good point, but on the flip side, if the new versions of fgl is much
better than the old version and is eventually taken into the Haskell
Platform, then does this mean that the old version will be deprecated
and eventually removed, or will they both be kept around for the long
term?<br>
<br>
For comparison, as I understand it seems that Python has generally had
the strategy of keeping around old packages for a long time for the
purpose of backwards compatibility. When a new and much better version
comes along they would give it a new name and mark the old package as
being deprecated --- at least for a while; after a long period of
deprecation they would eventually remove the old package.<br>
<br>
<blockquote
cite="mid:AANLkTilBPTVJ1iQOJtZvy_jKIkE4SZHXlVKGSJNejxZI@mail.gmail.com"
type="cite">
<div class="gmail_quote">
<div>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. =)<br>
<br>
</div>
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. ;)<br>
</div>
</blockquote>
<br>
Fair enough. :-) I am willing to agree that this makes sense as a
good short-term pragmatic solution, regardless of whether it is the
ideal long-term solution.<br>
<br>
Cheers,<br>
Greg<br>
</body>
</html>