upgrading GHC

[Henning Thielemann]

 I did now spend some days(!) on making only some of my packages
compatible to both GHC-6.4.1 and GHC-6.8.2. The amount of adaption work
increased with every GHC update for me, also because the number of
installed packages constantly grew. I'm hardly able to manage this work
for GHC-6.10, many packages will then go 'outdated', maybe only weeks
after their release. Some people wonder, why not simply upgrade. There are
many reasons: This way you can easily fall into a gap between dependent
packages that are still not updated to GHC-6.8.2 and others that are
already updated, but not backwards compatible. Compiler versions are
different in usability, bugs and annoyances. Namely, GHC-6.4.1 introduced
wrong warnings on apparently superfluous imports and a bug that let one of
my modules become uncompileable because of the compiler running out of
memory, GHC-6.6 replaced working filename completion by only partially
working identifier completion (it was certainly not a good idea, to remove
the old behaviour completely, before the new one worked reliably, but it
happened and we have to cope with), GHC-6.8.1 had a bug in compilation.
So after investing much time in upgrading you might encounter that your
programs don't work anymore or usability decreased considerably and you
have the choice to wait for the next compiler release, try to compile the
HEAD version from repository yourself (good luck!) or turn everything back
to the old version. Even if the compiler does only get better with respect
to features, you might decide not to upgrade, because the newer version
consumes more memory or is slower due to more features that the compiler
must handle.
 Every GHC update so far forced me to recompile my packages, broke some
code, either by new class instances, modules being replaced by newer ones,
shifting modules between packages. Sometimes the update helped improving
the code, either when the compiler emitted new warnings or when internal
functions were changed, and I became aware, that I was using internal
functions. But it is very hard to get a library compiled on different
compiler versions, not to mention different compilers. This is especially
nasty if you are working in an institute (like the universities I worked
at in the past) with different machines with very different software
installations. We have some Solaris machines here with GHC-5, which I do
not administer, Linux machines with GHC-6.4.1, GHC-6.6.1 and so on. I
cannot simply push around patches with darcs because every machine needs
separate package adaption.
 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.

 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. 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?

 Don't misunderstand me. I embrace tidying the libraries but I urge to do
it in a more compatible manner. 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? 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.