Hi,

Thanks, Ben, that sounds very interesting. Allow me to provide the following perspective.
It seems that those `*-internal` packages take the role of a static library's symbol table in the absence of a fixed ABI: 
It allows clients (such as `base` and `template-haskell`) to link against fixed, internal implementations provided by GHC.
"Reinstallable" then just means that a library can be linked against multiple different GHC versions providing the same set of internal APIs.

But perhaps this analogy is not all to useful, given the clash with the traditional use of the term "linking" and "static library".

Cheers,
Sebastian

Am Fr., 20. Okt. 2023 um 12:35 Uhr schrieb Andrei Borzenkov <andreyborzenkov2002@gmail.com>:

>  the `List` type provided by `base-X.Y.Z` and `base-X.Y.Z'` may differ. This is not actually true, `List` will obviously live in `ghc-internal` and `ghc-internal` would be the same for `base-4.9` and for `base-4.7.1`. This raises the question about do we really need to depend on `base` in `template-haskell`? Perhaps we may be satisfied by small set of things that will contain `ghc-internal`?

20.10.2023 14:23, Ben Gamari writes:
Viktor Dukhovni <ietf-dane@dukhovni.org> writes:


On Tue, Oct 17, 2023 at 04:54:41PM +0100, Adam Gundry wrote:


Thanks for starting this discussion, it would be good to see progress in
this direction. As it happens I was discussing this question with Ben and
Matt over dinner last night, and unfortunately they explained to me that it
is more difficult than I naively hoped, even once wired-in and known-key
things are moved to ghc-internal.

The difficulty is that, as a normal Haskell library, ghc itself will be
compiled against a particular version of base. Then when Template Haskell is
used (with the internal interpreter), code will be dynamically loaded into a
process that already has symbols for ghc's version of base, which means it
is not safe for the code to depend on a different version of base. This is
rather like the situation with TH and cross-compilers.

To avoid that problem, GHC's own dependency on "base" could be indirect
via a shared object with versioned symbol names and a version-specific
SONAME (possibly even a private to GHC SONAME and private symbol version
names).  Say "libbase.so.4.19.1".


The problem here is deeper than simply the symbol names. For instance,
the `List` type provided by `base-X.Y.Z` and `base-X.Y.Z'` may differ.
Since lists are used in the `template-haskell` AST, we would be unable
to share lists between `template-haskell` and `ghc`.

As noted in my recent reply elsewhere in the thread, this can be avoided
by communicating via serialisation instead of heap objects.

Cheers,

- Ben



_______________________________________________
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
_______________________________________________
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs