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.