upgrading GHC

[Henning Thielemann]

On Thu, 21 Feb 2008, Duncan Coutts wrote:

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

Nice idea.

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

I can't follow here. I think it must be possible to provide a base-1.1
which exports the same modules as base-1.0 but gets them from other
packages. It can be considered the last version of the base-1 series and
the transition to base-2.0.

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

With respect to "4. Allow packages to re-export modules"
  Is it a good idea to include the versioning in the language? I see no
need for it. I thought it could be done by 'ghc-pkg' to re-export modules.
Btw. I had problems with hidden packages in GHC-6.4.1. They still interfer
with other package versions, and thus I have to unregister all versions of
a package but one, in order to get something compiled. Is this a known
issue of GHC-6.4.1 or am I expecting the wrong behaviour of ghc-pkg? I
thought the exposed version is visible in GHCi and without -package
option, whereas the hidden but registered packages can be imported with
-package and thus Cabal.

I find the solution "4.3 Don't rename base" the best one. Is this the way
for GHC-6.10?

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

Now, a package for FunctorM for GHC>=6.6 and Traversable for GHC<6.6 would
be great.