[Haskell-cafe] Re: Proposal: register a package as providingseveral API versions

Claus Reinke claus.reinke at talk21.com
Tue Oct 16 11:41:11 EDT 2007


>> I have another concrete proposal to avoid things breaking so often.  Let us
>> steal from something that works: shared library versioning on unixy systems.

indeed!-) there are established workarounds that are needed to 
make that system work as it does, so it is a good idea to check
whether cabal has the means to cover those situations.

>> The above declaratively expresses that libcurl-3.3.0 provides the version 3 API
>> and the version 2 API.
>> 
>> This is the capability that should be added to Haskell library packages.
>> 
>> Right now a library can only declare a single version number.  So if I update
>> hsFoo from 2.1.1 to 3.0.0 then I cannot express whether or not the version 3 API
>> is a superset of (backward compatible with) the version 2 API.
> 
> Certainly, this is something we want to support.  However, there's an 
> important difference between shared-library linking and Haskell: in 
> Haskell, a superset of an API is not backwards-compatible, because it has 
> the potential to cause new name clashes.

yes, one would need to define what it means for one api to be 
compatible with another. even so, i think that permitting a single 
package to act as a provider for multiple versions of an api is
a necessary feature, even more so if loose dependency specs
like 'base', or 'base >= 1.0' are going to be discouraged.

> It could be done using the tricks that Claus just posted and I followed up 
> on.  You'd need a separate package for hsFoo-2 that specifies exactly which 
> bits of hsFoo-3 are re-exported.  Given some Cabal support and a little 
> extension in GHC, this could be made relatively painless for the library 
> maintainer.

are those tricks necessary in this specific case? couldn't we
have a list/range of versions in the version: field, and let cabal
handle the details?

aside: what happens if we try to combine two modules M and N
that use the same api A, but provided by two different packages
P1 and P2? say, M was built when P1 was still around, but when
N was built, P2 had replaced P1, still supporting A, but not 
necessarily with the same internal representation as used in P1.

claus



More information about the Haskell-Cafe mailing list