Stefan O'Rear wrote:
On Wed, Aug 15, 2007 at 02:34:22PM +0100, Duncan Coutts wrote:
Cabal configurations should make this situation better. Cabal does support ghc back to 6.2.2 and with a suitable .cabal file it should be possible to make most progs work with a range of compiler versions.
I'm not so sure. Cabal configurations look like they will fix the problem, but given a few years every .cabal file out there will look like a pre-autoconf C program's config.h, just a huge tangle of feature tests and conditional module usages...
I'd much prefer a situation where the (much smaller number of) library authors carry the burden of compatibility; maybe something like
{- in base-2.0's .cabal -}
Provides: fps-1.0 by { Data.ByteString* }
Do we need to cater to situations in which Cabal, or old packages' .cabal files, aren't upgradable? I'd guess not, because then why would you be able to install newer packages that need any of this, either? Assuming we don't... New versions should depend on whatever the newest name for the package is (e.g. "bytestring"). There are old names like "base" and "fps" that provide older versions of the same thing. Somehow (update their cabal files? Bake knowledge into a centralized place like a part of Cabal?) these names should be translated so that (requiring bytestring in GHC 6.6) pulls in (base) instead...... too bad for programs that need a newer version of ByteString perhaps? Or, a "bytestring" might be installable...
... which unfortunately doesn't handle splits (FiniteMap etc) anywhere near as well.
Why have package names, again? It seems using modules names instead would completely fix this problem, and with the small restriction that a module name, once used, is not reused for something incompatible, solves the versioning problem as well.
1. upgrades make incompatibility anyway, sometimes 2. sometimes it is (or should be? or is likely to be, sometime in future?) decided that a module change is for the better 3. module Main... (divergent leaves are not a problem as long as it remains a tree, not generally an acyclic graph, of dependencies; module Main dep. on (A which dep. on C{-1-}) and (B which dep. on C{-2-}) won't work in ghc<6.6 and I don't know about other Haskell implementations) Module names allow you to have sort-of-broken packages and libraries without them interfering with normal package usage. Package and dependency renaming can be performed without any change to Haskell source code, which is viewed as a desirable partitioning. Isaac