Re: Reinstallable - base

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 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 listghc-devs@haskell.orghttp://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