GHC and Haskell 98

[Simon Peyton-Jones]

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.