stability vs latest features

[Henning Thielemann]

On Wed, 15 Aug 2007, Malcolm Wallace wrote:

> > > My concrete example is that I submitted patches to make Gen an
> > > instance of Applicative but was told this wasn't ok since it needed
> > > to remain compatible with ghc-6.2 or something.
>
> Isaac Dupree <isaacdupree at charter.net> wrote:
> > Personally, I don't see the need for new versions of libraries to stay
> > compatible with such old versions of GHC (is there a specific old-ghc
> > use case I'm unaware of?).
>
> Yes.  The default version of ghc provided by our local tech support
> people for the use of all students and staff (i.e. those who are not
> specifically researching Haskell) is ghc-6.2.2.  They have a huge number
> of software packages to maintain, and so their upgrade cycle is
> necessarily slow.  Now these (mostly novice) users of Haskell are the
> ones who are mostly quickly going to give up in disgust if some piece of
> software they download from the 'net fails to build because it requires
> newer versions of all kinds of things they have not even heard of.

 Unfortunately GHC broke something in each recent version, mostly without
need. I started with 6.0. Update to 6.2 was quite smooth, or I did forget
the trouble. :-) Then I had to update, because many packages required
that, at least required Cabal, and this in turn required GHC-6.4. Update
to 6.4 made FiniteMap deprecated. Bad looking warnings although the code
was still perfectly ok. Update to 6.6 removed FiniteMap, FastPackedString
'fps' disappeared as package. Thus Cabal packages depend on compiler
versions. And what is the conclusion for Cabal programmers? Introduce
macros? Actually, after a test of GHC-6.6 I do not want to update because
file name completion was replaced by identifier completion. I'm afraid I
have to update sooner or later, because other packages require GHC-6.6.
There are already several packages which don't specify 'fps' dependency,
although they need the related modules.
 I wrote a program for managing preprints. It generates the following:
  http://www.math.uni-bremen.de/zetem/DFG-Schwerpunkt/preprints/
 When I left the team I handed the program over to a colleague, who has no
idea of Haskell. He can start it, but he cannot maintain it. It runs in
interpreter mode. This way it runs on both Linux and Solaris, it doesn't
require a big compiled binary, and I saved the work of designing a shell
interface. Every time a new GHC version comes out, it is installed by the
responsible admin, and then my program doesn't run anymore, or at least,
emits confusing warnings. It's annoying.
 Yes, there is a need to keep things clean, and this often requires
incompatible changes, but incompatible changes should only be done if
things become really better.