Friends, this is to ask your opinion about a possible change in GHC 7.2. The current implementation in GHC 7.2 is Plan A below. Plan A is a bit easier for us, but I think it may be a bit draconian, and therefore propose Plan B as an alternative. Opinions? Simon ============================================== With GHC 7.0 if you say ghc -c Main.hs the import of Prelude, whether implicit or explicit, will come from package 'base'. This is also true if you say ghc -c Main.hs -package haskell98 The package 'haskell98' exposes 'List' and 'Random' but not 'Prelude'. That still comes from 'base'. This isn't good, because it means that if in the future we change 'Prelude' in package 'base', a Haskell98 module might fail to compile. And later iterations of Haskell might well want to expand or change the Prelude. There appear to be two alternatives: (Plan A) Add a module 'Prelude' to package 'haskell98'. Now you can compile a pure H98 program thus: ghc -c Main.hs -hide-all-packages -package haskell98 (Cabal puts the -hide-all-packages in for you.) And this will continue to work even if later iterations of Haskell change the Prelude. BUT (A) means that this module becomes un-compilable: module Main where import Random import Data.List Why? Because 'Random' comes from 'haskell98' and 'Data.List' comes from 'base'. But if you say ghc -c Main.hs -package base -package haskell98 then the (implicit) import of 'Prelude' will say "Ambiguous module name: Prelude", because it's exported by both 'base' and 'haskell98'. To fix this you have to change 'import Random' to 'import System.Random'. But the latter's API is different, so you may have to change the source code that uses it. So the second alternative is this: (Plan B) Like Plan A, but in addition, if you say "{-# LANGUAGE Haskell98 #-}" in the file, or -XHaskell98 on the command line, the implicit import of Prelude comes from package 'haskell98', provided -package haskell98 is specified, but regardless of what other in-scope packages expose a Prelude module. Variation: an explicit 'import Prelude' is similarly directed to package 'haskell98' as well. So: Under Plan A, some Hackage packages will become un-compilable, and will require source code changes to fix them. I do not have any idea how many Hackage packages would fail in this way. Unser Plan B, Hackage package that compile now will continue to compile, if their Cabal file is altered. No source code changes. (Well, unless they depend on some innards of GHC.IO or something like that.) But Plan A is simpler. And by breaking packages it will encourage [force] libraries that use a mixture of H98 and more modern modules to move towards the more modern story.