On 3/19/07, Simon Peyton-Jones
| > base isn't compatible between major ghc versions (6.6/6.8). so you may | > use only base 2.0 with 6.6 or base 3.0 with 6.8. | | This seems wrong to me (though I'm quite new at this, so there could | be something obvious I'm missing). I understand that ghc-6.6 expects | certain types and functions to be defined at particular places within | base, but most names aren't like that. One could declare that base-2.x | defines all the magic names in the places ghc-6.6 expects them, but | other names can be moved around between 2.x and 2.(x+1). Then ghc-6.8 | would expect the names where base-3.x places them, and so on.
That's more or less it. I documented this here http://hackage.haskell.org/trac/ghc/wiki/Commentary/Compiler/WiredIn
In the vocabulary of that page * You can change neither the definition nor the location of wired-in things * You can change the definition, but not the location, of known-key or Orig-RdrName things
By "location" I mean the name and defining module.
The Wiki page tells you how to find out exactly which names fall into which category.
Does that help? If anything is unclear, let's improve the Commentary
| So, to solve the immediate problem you're complaining about, it might | be more practical to pull the "bottom" (GHC/Prim*.hs) out of base into | something like ghc-prim for ghc-6.8 rather than to prevent new modules | from being added to the top.
We have considered doing that. But I don't follow how it would help you here.
Thanks, Simon, I hadn't realized it was already possible to release a new base version for the same compiler. The ghc-prim suggestion is probably irrelevant then. To resolve the deadlock around System.FilePath, I propose that Neil be allowed to submit it to base (so that it's definitely in a logical package for ghc-6.8 even if the rest of the refactoring doesn't happen), and then Bulat and anyone else who wants to use it before then should release base-2.1 with System.FilePath backported. Does that sound reasonable? Jeffrey