| Please reconsider striving for a form of cross-version compatibility | that will solve this issue for GHC Api clients, as a priority on par with | binary compatibility. ... | Perhaps Haskell' should re-consider the idea of having an | explicit representation of module interfaces, to get all that | work out of the dark and in the open?
I find it very easy to get myself confused here. There are several reasons that an old package P may be unusable with a new version of GHC: 1. We often change .hi-file formats between versions of GHC. I am very reluctant indeed to deny ourselves this opportunity, because interface-file flexibility *the* way in which we can convey new compile-time info across module boundaries. 2. Rather less often we make some change to calling conventions, or pointer-tagging, or suchlike, which makes the compiled code simply incompatible. Even changing the name of runtime system goop that is called from Haskell code would have this effect. 3. Package P probably depends on package 'base', and that tends to change between versions of GHC. That rate of change will slow down, now that 'base' has less stuff in it, but the very process of reducing its size changes its interface. Explicit module interfaces won't help any of these things. Recompiling from source (which Cabal makes easy) should solve many of them. I'm not denying that there is a serious problem. I just don't see a solution that doesn't tie our hands unacceptably. Simon _______________________________________________ Cvs-ghc mailing list Cvs-ghc@haskell.org http://www.haskell.org/mailman/listinfo/cvs-ghc
