ChrisK wrote:
Simon Marlow wrote:
Several good points have been raised in this thread, and while I might
not agree with everything, I think we can all agree on the goal: things
shouldn't break so often.
I have another concrete proposal to avoid things breaking so often. Let us
steal from something that works: shared library versioning on unixy systems.
On Max OS X, I note that I have, in /usr/lib:
lrwxr-xr-x 1 root wheel 15 Jul 24 2005 libcurl.2.dylib ->
libcurl.3.dylib
lrwxr-xr-x 1 root wheel 15 Jul 24 2005 libcurl.3.0.0.dylib ->
libcurl.3.dylib
-rwxr-xr-x 1 root wheel 201156 Aug 17 17:14 libcurl.3.dylib
lrwxr-xr-x 1 root wheel 15 Jul 24 2005 libcurl.dylib ->
libcurl.3.dylib
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.
Once it is possible to have cabal register the hsFoo-3.0.0 also as hsFoo-2 it
will be easy to upgrade to hsFoo. No old programs will fail to compile.
Who here knows enough about the ghc-pkg database to say how easy or hard this
would be?
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.
Cheers,
Simon
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
