Claus Reinke wrote:
I've never found the rationale for GHC's binary incompatibility
very convincing (yes, we want cross-package optimizations, and
yes, we do like it if GHC V(n+1) does a better job at compiling
package P than GHC Vn did; but why can't GHC V(n+1) do
at least as good a job as GHC Vn with package P compiled by
GHC Vn? augment the .hi-files format, don't replace it completely;
or have a generic it-works-with-all-versions-but-wont-be-fast
section, preceded by a preferably-use-this-for-speed-version-x section).
It's more than that: the RTS ABI changes between versions too. For
example in 6.8 we introduced pointer tagging, which is a complete ABI
change. In 6.12 we'll probably introduce the new code generator,
which will no doubt include a complete revamp of the calling
conventions: hence complete ABI incompatibility.
Right, thanks for pointing that out. But that only affects GHC Api
clients using the full range, front-end/back-end/runtime, such as GHC
itself, or GHCi. While many GHC Api clients, like Haddock or HaRe, only
need to use the frontend, and for them, a partial solution that does not
address the RTS ABI issue would be sufficient, right?
And then, a Haddock 2 built with V1 could process source code
depending on libraries built with V2, by reading the portable parts
of their interface files, even if GHC V1 wouldn't be able to link or
load the V2-built libraries.
Without such a partial solution, GHC Api based tools like Haddock 2
seem to be severely crippled compared to their non GHC Api based
predecessors, as the Haddock GHC build issues demonstrate.
I think you've veered onto a different (but related) topic here. I was
talking about binary compatibility between libraries, you're talking about
allowing the GHC API to make use of .hi files generated by a different
version of GHC.
So certainly these topics are related in that if we want binary
compatibility then having .hi-file compatibility would also be useful, so
that we can *compile* against old libraries, not just link against them.
You can have binary compatibility without .hi-file compatibility (due to
.hi format changes), and vice versa. Hmm, complicated isn't it.
I'm not proposing right now to strive for any kind of .hi-file
compatibility except between minor releases of GHC. That is, I think it
would be nice, and quite easliy achievable, for GHC 6.8.3 to read 6.8.2's
.hi files (perhaps it can already, I don't know).
Haddock will be part of the Haskell Platform, so it'll come with a set of
compatible tools and libraries, so most users won't encounter any problems.
I've sometimes wondered why we can make GHC V1-compiled code
available to C clients, but not to GHC V2-compiled clients (or even to
Hugs/yhc/etc). I assume the reasons are efficiency and non-automated
data type conversions?
We can't export a complete Haskell API to C - the FFI can only use a fixed
set of primitive data types.
In the special case of linking GHC V2-built libraries with GHC V1-built
libraries, couldn't each library use its own version of an RTS package,
as it would if exported via FFI?
there are so many problems with this I don't know where to start. Who does
the marshalling? who generates the marshalling code? what about
cross-runtime pointers? Have you thought this through? :-)
Ah, I'd been wondering about that when I saw the patch notice,
but couldn't see how it would help with cross-GHC-version
compatibility: wouldn't the recompilation checker just notice
that the fingerprint isn't the newest possible and therefore want
to rebuild the old library?
I don't think I understand this question, but I'll try to answer. It helps
with cross-version compatibility by telling us when we have managed to
create a compatible ABI - the fingerprints will be the same (this glosses
over a large number of details and problems, many of which I haven't
thought through yet, but that's the basic idea).
Cheers,
Simon
_______________________________________________
Cvs-ghc mailing list
Cvs-ghc@haskell.org
http://www.haskell.org/mailman/listinfo/cvs-ghc
