On Thu, 2008-02-21 at 08:12 +0100, Henning Thielemann wrote:
It was said, that Cabal would work also with GHC-6.2. I didn't get it running and then switched to GHC-6.4. It was said, that multiple versions of GHC can be installed on the same machine. That's somehow true, but e.g. runhaskell cannot be told which actual GHC binary to use, and thus it is not possible to run Cabal with a compiler or a compiler version different from the compiler to be used for the package.
It's always possible to: ghc-6.4.1 --make Setup.hs -o setup ./setup configure ...etc rather than using whatever ghc runghc/runhaskell finds on the $PATH. I keep 3 versions of ghc installed this way to test Cabal and other stuff.
I decided to upgrade to Cabal-1.2, which also needed installation of filepath. I know that installation could be simplified with cabal-install, which has even more dependencies, and thus I canceled this installation project. Then I have equipped my Cabal files with a switch on splitBase, which merely duplicates the globally known information that former base-1.0 package is now split into base-2.0 or base-3.0 and satellites. It doesn't give the user any new value, but costs a lot of time for the package maintainer. I wonder if it would have been simpler to ship GHC-6.8 with a base-1.0 package or provide it on Hackage that just re-exports the old modules in the known way.
We know this issue is a mess. We've discussed it at length. http://hackage.haskell.org/trac/ghc/wiki/PackageCompatibility Sadly at the moment it is impossible to supply a base-1.0 with ghc-6.8 because packages cannot re-export modules and even if they could, ghc and cabal would have no way to figure out if a particular program was intended to use one or the other.
This would allow the usage of packages that are in different state of adaption and it will reduce the amount of work for package maintainers considerably. I also predict that the switch on different package arrangements in the Cabal file will grow in future, eventually becoming error-prone and unmaintainable. How many GHC versions do you have installed simultaneously in order to test them all?
Personally, I have 3. :-)
Don't misunderstand me. I embrace tidying the libraries but I urge to do it in a more compatible manner.
So do I. Tell is what you think about the suggestions on the PackageCompatibility page above.
Deprecated packages do not need to be banned from the internet. It is not necessary to enforce programmers to adapt to changes immediately, it is better provide ways for doing the changes later, when time has come, in a smooth manner. I thought it was a good idea to adapt to FunctorM in GHC-6.4 quickly instead of rolling my own class. Then, two GHC releases later this module disappeared, was replaced by Traversable. I thought it was good style to rewrite code from List.lookup to FiniteMap in GHC-6.0, in GHC-6.4 it already disappeared, replaced by Data.Map. Why is it necessary to make working libraries obsolete so quickly?
Though the advantage of more packages is that we can have (and there is) a compatibility package for the old FiniteMap.
I thought using standard modules is more reliable (because of more testers, more possible maintainers) than using custom modules. If libraries change so quickly this forces programmers to fork to their own modules.
Duncan