Simon Peyton-Jones wrote:
| 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.
I'm suggesting that we aim to maintain all 3 kinds of compatibility between
minor releases of GHC, and allow breakages at a major release, in the same
way that we allow API changes at major releases only.
Claus is asking that we use an extensible .hi-file format too, to allow
some GHC API clients to work with libraries compiled by a wider range of
GHC versions. I'm not sure how practical that is, though: what happens
when we introduce new type system extensions, so that the old GHC API can't
understand the types in the new .hi files?
Cheers,
Simon
_______________________________________________
Cvs-ghc mailing list
Cvs-ghc@haskell.org
http://www.haskell.org/mailman/listinfo/cvs-ghc
