On 17/06/2011 10:47 AM, Simon Peyton-Jones wrote:

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.

I favour Plan A. Reasoning: For many years of my previous professional life, I had to live with extreme backwards compatibility in the code base. This introduced a huge amount of inertia, to the point where past design mistakes became entrenched as 'features'. Forward progress became glacial. Very bad. Your plan A on the other hand strikes a really good balance: the only libraries affected are those which mix H98 and more modern modules. This means that the authors are already beyond Haskell 98, and realize that there is real value to go beyond that. So they should be reasonably amenable to continue to move forward. On the other hand, those who were very careful to stick to pure Haskell 98 (for whatever reason), have a very clear path for their code to continue to stay functional. They get all the backwards compatibility they desired when they chose to stick to pure Haskell 98. Plan B is actually more fragile in that respect, in that if they forget to be really really explicit about their code being pure Haskell 98, the resulting compilation errors do not make it obvious that that is actually the problem. This will in fact only get worse as time goes by. Jacques

At Fri, 17 Jun 2011 14:47:30 +0000, Simon Peyton-Jones wrote:

(Plan A) Add a module 'Prelude' to package 'haskell98'. ... (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.

This is probably too much to ask, but if you were to do something like plan B, is there any possibility of generalizing the mechanism? For instance, suppose the -package flag took a colon-separated list of packages, like " ... -package haskell98:base -package mtl ...". The meaning would be to include both haskell98 and base, but, unlike "-package haskell98 -package base," to accept ambiguous module names within a single -package argument and resolve them to the first matching package in the list. Something like this could be useful for SafeHaskell, where, for compatibility, one might want to create safe "overlay" packages. (And of course, the GHC PackageImports extension would still be there for cases where people need to do weird things.) David

On 17 June 2011 16:47, Simon Peyton-Jones wrote:

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.

Of the 372 direct reverse dependencies of haskell98: http://bifunctor.homelinux.net/~roel/cgi-bin/hackage-scripts/revdeps/haskell... there are 344 which also depend on base (See http://hpaste.org/47933 for calculating the intersection). Am I correct that a package which depends on both base and haskell98 will always fail to build when the Prelude is also exported from haskell98? (Unless of course the package uses the PackageImports extension) I don't know how many of these 344 packages use PackageImports or have upper bounds on their haskell98 dependency (I guess not many). So I guess many of these 344 will break. Still I'm in favour of plan A since it's simple and discourages mixing haskell98 with more modern modules. Regards, Bas

Simon Peyton-Jones writes:

(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.

So Plan A also involves hiding the haskell98 package by default?