upgrading GHC

[Duncan Coutts]

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