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