| Please reconsider striving for a form of cross-version compatibility
| that will solve this issue for GHC Api clients, as a priority on par with
| binary compatibility.
...
| Perhaps Haskell' should re-consider the idea of having an
| explicit representation of module interfaces, to get all that
| work out of the dark and in the open?
I find it very easy to get myself confused here. There are several reasons
that an old package P may be unusable with a new version of GHC:
As Simon M points out, there are also several scenarios in which
backwards compatibility issues arise: (a) relinking modules without
recompiling their importers, (b) building against old compiled modules
without rebuilding those modules, (c) old GHC Api frontends trying
to process source in the context of new interface files, (d) old GHC
Api clients trying to load code in the context of new packages/rts.
(a) seems to be what Simon M is after (the main application I can
think of is changing dynamically loaded modules); (b) would allow
to use existing libraries in updated GHCs (particularly interesting
for complex, but stable, things like GUI libraries); (c) is what
Haddock2 has been stumbling over, and what will affect HaRe in
future; (d) is the fairly hopeless case at the moment, but perhaps
also the least urgent?
Personally, I'd like to see solutions to (b) and (c), and can see
the need for (a) as well. Perhaps one solution, stable module
interfaces, serves both (a) and (b), but (c) and (b) both seem
to depend on stable interface formats (or at least monotonically
increasing interface file information with the ability to extract
stable/older subsets).
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.
2. Rather less often we make some change to calling conventions,
or pointer-tagging, or suchlike, which makes the compiled code
simply incompatible. Even changing the name of runtime system
goop that is called from Haskell code would have this effect.
Yes, that seems to be insurmountable at present. But its effect
should be limited to Api clients that actually need to use the RTS,
so while those clients will have to be rebuilt for each such major
RTS change, there is a lot of potential for non-RTS Api clients.
And for those clients which only use GHC's frontend to analyse
and transform Haskell source, backwards compatibility of interface
files would seem to go a long way towards avoiding trouble
(backwards compatible as in: old GHC's can extract their information
from new interface files, even if they may not understand all of the
new information in those files).
3. Package P probably depends on package 'base', and that
tends to change between versions of GHC. That rate of change
will slow down, now that 'base' has less stuff in it, but the very
process of reducing its size changes its interface.
If a package can't be rebuilt with a newer GHC/base, there is
no chance that it can be relinked without recompilation. If it
can be rebuilt, the success of that might still depend on
configuration time changes, so pure relinking might still not
work.
But for frontend clients (themselves built with GHC/base
version A) that try to analyse P's source in the context of
GHC/base version B, there shouldn't be a problem. Only
that there is a problem right now, because the GHC Api
in those clients won't be able to read the interface files in
the new context.
Explicit module interfaces won't help any of these things.
Haskell-level explicit module interfaces (similar to boot
files) could provide a GHC-version-independent description
of GHC-version-specific information in interface files:
- GHC A puts information set A into interface files
- GHC B puts information set B into interface files
- GHC B is newer than GHC A, so B interfaces contain
more useful info than A interfaces, and some of the
internal representation might have changed as well
- if there was a way to extract portable high-level interfaces
from low-level ones, even at the expense of losing some
information relevant to B's cross-package optimization,
GHC A might be able to work with sources in the
context of B's packages and interface files
Recompiling from source (which Cabal makes easy) should solve many of them.
I'm not denying that there is a serious problem. I just don't see a
solution that doesn't tie our hands unacceptably.
Since we agree that the issue is serious, I'm hoping for
a solution based on adding a level of abstraction that
hides some of the changes in interface files, for clients
that do not depend on RTS changes (in the packages
they need to analyse and process source files).
Such a solution would be partial, but it would help frontend
only clients of the GHC Api, without keeping you from adding
more info to interface files as you implement more exciting
optimizations.
Claus
_______________________________________________
Cvs-ghc mailing list
Cvs-ghc@haskell.org
http://www.haskell.org/mailman/listinfo/cvs-ghc
