Claus Reinke wrote:
Instead of working around them in each individual case, I'd really like
to see general solutions to the two issues of
1 updating ghc-paths and notifying existing clients
2 making (some) ghc api clients less dependent on a single ghc version
Most suggestions about this have been shot down in the past, iirc,
the closest to being possible were dynamic linking for 1 and some
cross-ghc-version reading of .hi-files for 2 (at the risk of losing
information, because the .hi-format itself would still change; so this
would work only for some ghc api clients, and only for a limited range
of ghc versions, but haddock ought to be among those clients).
dynamic linking will solve (1), but at this stage I don't think we have
time to get dynamic linking fully working and in the binary distributions
for 6.10.1. We might have it working in a build-from-source form, though.
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. Making an
extensible .hi format seems completely unrealistic - it's not just the
format that changes, but the semantics. "Losing inforamtion" might be
completely disastrous if you actually *needed* that information. Not to
mention the fact that trying to do both forwards and backwards
compatibility in anything but a trivial way gives you a quadratic-sized
testing surface, which is something we really have to worry about.
Cheers,
Simon
_______________________________________________
Cvs-ghc mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/cvs-ghc
