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

[Gregory Crosswhite]

On 6/23/10 3:29 PM, Edward Kmett wrote:
> 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. ;)

Oh, cool, so that's the plan?  Grr, if I had fewer projects I would 
volunteer to help out with this.  :-)

>
>     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.

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!"

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.

>     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. =)

Fair point.  :-)

>>         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.

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.
>
> 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.
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?

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.

> 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. ;)

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.

Cheers,
Greg
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20100623/86d866f8/attachment.html