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.
If the code to be processed does not use new language features,
just happens to be using libraries compiled with a newer GHC,
there should be no reason to update or rebuild the tool doing the
processing.
This is where GHC Api based tools currently fail: where pre-Api
tools probably re-processed the whole source including libraries
(which is what HaRe did - one reason it can't be used in a GHC
environment: no sources), or had to make do without information
about the libraries (how does Haddock 0.8 solve this, when the
libraries are only available compiled, not in source, btw?), Api
based tools process only the source at hand, relying on interface
files for information about the libraries.
Claus
_______________________________________________
Cvs-ghc mailing list
Cvs-ghc@haskell.org
http://www.haskell.org/mailman/listinfo/cvs-ghc
