Claus Reinke wrote:
- but if that isn't the case:
- ask ghc 6.11 to explain its .hi files in Haskell terms
ghc6.11 --show-iface-haskell libdir/*.hi -hsiodir hsi
- direct ghc-api 6.10 to consult hsi files for missing libs
GAC +RTS -hsidir hsi
So the fundamental problem with this is that when new features are
introduced in GHC 6.11, these features are not expressable in whatever
interface format is understood by the 6.10 API client. The guy who wrote
the code you're trying to process might not know or care about the new
features - they might be used in some library that is indirectly depended on.
e.g. suppose (hypothetically) we rewrote the array package to use type
families and shipped it with GHC 6.10.1. Most client code works unchanged.
But a GHC 6.8-compiled API client has no hope of understanding the
interfaces for the array library now; they use a type language that GHC 6.8
just doesn't grok.
This kind of backwards compatibility only works if you really fix the
language in which interfaces are expressed, and when we're doing things
like changing the type system that's not feasible.
Cheers,
Simon
_______________________________________________
Cvs-ghc mailing list
Cvs-ghc@haskell.org
http://www.haskell.org/mailman/listinfo/cvs-ghc
