Reinstallable - base

[Sebastian Graf]

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 at 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 at dukhovni.org> <ietf-dane at 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 listghc-devs at haskell.orghttp://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20231020/fcddf7fa/attachment.html>