upgrading GHC

Henning Thielemann lemming at henning-thielemann.de
Thu Feb 21 02:12:19 EST 2008

 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.
from the compiler to be used for the package.

which has even more dependencies, and thus I canceled this installation
which merely duplicates the globally known information that former
old modules in the known way. This would allow the usage of packages that
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?

it in a more compatible manner. Deprecated packages do not need to be
replaced by Data.Map. Why is it necessary to make working libraries
obsolete so quickly? I thought using standard modules is more reliable
their own modules.

More information about the Libraries mailing list