> As I've said before regarding (2), it's feasible to make the .hi
> format stable across minor releases of GHC, but not major releases.
Here is an idea that might help solve some of the "need exact version of
ghc to build haddock" style of problem.
Why not develop a _small_ stand-alone tool that reads the binary .hi
file and gives you back a useful subset of the information contained
therein. Something like ghc --show-iface. The information it _returns_
could be in a very stable format, even though the file format it reads
often changes. Its version would be linked to a specific ghc version.
A client calls the interface reader as a separate process. That is, it
is specifically _not_ a library, with all the problems that causes
through needing to re-compile the client every time your compiler is
upgraded. Instead, the interface reader supplies its output in a
well-specified format (text or binary) over the standard OS-level IPC
mechanism. When you upgrade the compiler, the client simply calls
the newer reader, without itself needing to be rebuilt.
I can even envisage driving the interface-reader through a small query
language (maybe on the command-line, maybe interactive). New interface
file features, as they are developed, might be reflected in additions to
the language. (The design would be careful to ensure that unknown
queries get sensible return answers, to allow for the possibility of
future extension.)
The core of this proposal is essentially simple:
* codify a number of data structures containing useful information
that can be extracted from a .hi file.
* write a simple translator from ghc's internal data structures to
these externally specified structures.
* ensure that the latter (but not the former!) is updated for every
new release of ghc.
Regards,
Malcolm
_______________________________________________
Cvs-ghc mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/cvs-ghc
