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.
By all means, *adding* new compile-time info to interface files
should be ok, shouldn't it? The incompatibility starts when old
GHCs can't extract their subset of info from new formats.
What about ghc --show-iface, or something like it? Lets assume
that
- the output of such a command could abstract from GHC-version
specific info, or mark such info in a way that could be ignored
by other GHC versions
- the portable parts of that output could actually be read back in
by GHC Api clients
then, if a GHC 6.9 Api frontend client needs to process sources that
depend on GHC 6.10-processed libraries, it could ask GHC 6.10
to dump the interface info in a portable form, and read it in for
further processing. For instance, one version of Haddock could
be used to build docs for libraries with several versions of GHC,
by asking said GHC for a little assistance in explaining its .hi files.
Alternatively, since this would only work for future GHC versions,
there could be separate backwards translators for interface files,
basically composing the old show with the new read, and perhaps
some generic translation in the middle?
If either of these could be made to work, backwards compatibility
of interface files wouldn't restrict your implementor's liberties;-)
Claus
_______________________________________________
Cvs-ghc mailing list
Cvs-ghc@haskell.org
http://www.haskell.org/mailman/listinfo/cvs-ghc
