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.
_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
