<div dir="ltr"><div>Hi,</div><div><br></div><div>Thanks, Ben, that sounds very interesting. Allow me to provide the following perspective.</div><div>It seems that those `*-internal` packages take the role of a static library's symbol table in the absence of a fixed ABI: </div><div>It allows clients (such as `base` and `template-haskell`) to link against fixed, internal implementations provided by GHC.</div><div>"Reinstallable" then just means that a library can be linked against multiple different GHC versions providing the same set of internal APIs.</div><div><br></div><div>But perhaps this analogy is not all to useful, given the clash with the traditional use of the term "linking" and "static library".</div><div><br></div><div>Cheers,</div><div>Sebastian<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Am Fr., 20. Okt. 2023 um 12:35 Uhr schrieb Andrei Borzenkov <<a href="mailto:andreyborzenkov2002@gmail.com">andreyborzenkov2002@gmail.com</a>>:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><u></u>
<div>
<p>> <span style="white-space:pre-wrap">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`?
</span><br>
<span style="white-space:pre-wrap"></span></p>
<div>20.10.2023 14:23, Ben Gamari writes:<br>
</div>
<blockquote type="cite">
<pre>Viktor Dukhovni <a href="mailto:ietf-dane@dukhovni.org" target="_blank"><ietf-dane@dukhovni.org></a> writes:
</pre>
<blockquote type="cite">
<pre>On Tue, Oct 17, 2023 at 04:54:41PM +0100, Adam Gundry wrote:
</pre>
<blockquote type="cite">
<pre>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.
</pre>
</blockquote>
<pre>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".
</pre>
</blockquote>
<pre>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
</pre>
<br>
<fieldset></fieldset>
<pre>_______________________________________________
ghc-devs mailing list
<a href="mailto:ghc-devs@haskell.org" target="_blank">ghc-devs@haskell.org</a>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs</a>
</pre>
</blockquote>
</div>
_______________________________________________<br>
ghc-devs mailing list<br>
<a href="mailto:ghc-devs@haskell.org" target="_blank">ghc-devs@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs</a><br>
</blockquote></div>