- 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.
a) how problematic are indirect dependencies on new features going
to be in practice? For Haddock to process a module X, it will read
the interface files of all imported modules (implicitly, via ghc api) -
will that necessarily fail if an indirectly imported module uses but not
re-exports new language, or could indirect imports be inspected on
demand?
b) _if_ there is an actual dependency, direct or indirect, on new language
features, there isn't much the ghc api can do; I consider that a valid
reason for upgrading tools, whether they use the ghc api or not.
If there is no actual dependency, ie, the client module builds fine with
the old or the new import, but the ghc api has to look at the import
and fails because of the changes in it, we are back to plan B, I suppose.
Or plan A, if we are lucky and GAC still builds with the new ghc.
to recap: have GAC-x.x and want to process sources using ghc-y.y
plan A: rebuild GAC with the ghc for which you want to process sources
plan B: rebuild sources and build-depends with GAC's ghc
plan C: help GAC-x.x to process sources in ghc-y.y
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.
If this language change is visible in the modules being processed, this
is a valid reason for a tool upgrade.
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.
Currently, none of A/B/C seem practical, which severely hampers
the impact of the ghc api on tool development. Having to upgrade
all libraries with each ghc release is bad enough, having to do the
same for all ghc api based tools is going to be worse, and having
to keep multiple versions of libraries and tools, to get a consistent
set of each for every ghc release is going to be real fun.
But if there is really no way to avoid this version chaos, it needs
to be planned for: just as each ghc has its own library directories,
it now needs its own bin directories, and since ghc and ghc api
clients need to form a consistent set, there needs to be a way to
switch ghc and ghc api clients together. When editing PATH, the
easiest would be to install all ghc api client executables in ghc's
bin directory, by default? But when calling ghc or other ghc api
clients with an explicit path, how do we ensure that they call
consistent versions of each other (similar to ghc and ghc-pkg
at the moment, but extended to haddock, and hare, and ides,
and ..)?
Claus
_______________________________________________
Cvs-ghc mailing list
Cvs-ghc@haskell.org
http://www.haskell.org/mailman/listinfo/cvs-ghc
