Claus Reinke wrote:
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?
If the code to be processed uses new language features, that is
a valid reason to update the tool doing the processing, as before.
But what if the *libraries* use new language features in their APIs? Or
what if we change the language in which types are expressed (e.g. by adding
equality constraints)? Then the old API tool has no hope of understanding
the new .hi files, regardless of whether we use an extensible format.
I'm sure we could arrange that it could somehow ignore the bits it doesn't
understand, but that way leads to madness: what happens when those bits are
referred to by other bits, and how do we reliably test that this backwards
compatibility works properly? No no no. The right way is to have
well-defined points at which we're allowed to change the .hi file format,
and the best time is a major release when we're changing all sorts of other
things in incompatible ways.
(how does Haddock 0.8 solve this, when the libraries are
only available compiled, not in source, btw?),
Haddock 0.8 has its own interface files (the .haddock files). They contain
names only - the list of names exported by each module - and no types.
Cheers,
Simon
_______________________________________________
Cvs-ghc mailing list
Cvs-ghc@haskell.org
http://www.haskell.org/mailman/listinfo/cvs-ghc
