prelude-compat, prelude2010

Here is my attempt to make packages compile with GHC-7.10 and older compilers without warnings: https://hackage.haskell.org/package/prelude-compat-0.0/candidate https://hackage.haskell.org/package/prelude2010-0.0/candidate The idea is that prelude2010:Prelude maintains the export list of haskell2010:Prelude such that you are saved both from identifier conflicts and warnings about redundant imports of Data.Foldable etc. Unfortunately, when I try to use it on GHC-7.8.4 together with base-noprelude, I am told that base-noprelude cannot be installed with Cabal-1.22. :-( However, when thinking about adapting all my packages to this work-around I'd prefer to switch to the real solution, namely split base packages that can be upgraded independently from GHC.

On Sat, 2 Jan 2016, Henning Thielemann wrote:
Here is my attempt to make packages compile with GHC-7.10 and older compilers without warnings:
https://hackage.haskell.org/package/prelude-compat-0.0/candidate https://hackage.haskell.org/package/prelude2010-0.0/candidate
I have now uploaded the packages to https://hackage.haskell.org/package/prelude-compat https://hackage.haskell.org/package/prelude2010
The idea is that prelude2010:Prelude maintains the export list of haskell2010:Prelude such that you are saved both from identifier conflicts and warnings about redundant imports of Data.Foldable etc.
The prelude-compat package provides the old Prelude as module named Prelude2010. This package is needed as an intermediate step but it is useful of its own. It does not cause any module name conflict thus I even recommend its use over prelude2010. Use of the prelude2010 is simpler for the package maintainer but more obtrusive to the package user. It is very likely that users get prelude2010 installed as a deep dependency of a package and then are no longer able to run GHCi due to the conflicting Prelude modules. They first have to figure out that the prelude2010 package is the problem and they must hide prelude2010 (or base) in order to resolve the conflict. Additionally, prelude2010 depends on base-noprelude which requires brand new Cabal-1.24. I still think these packages provide only a work-around and the real solution would be to make the base package independent from GHC.
participants (1)
-
Henning Thielemann