Reinstallable - base
Ben Gamari
ben at smart-cactus.org
Fri Oct 20 10:23:29 UTC 2023
Viktor Dukhovni <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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20231020/16cc82e9/attachment.sig>
More information about the ghc-devs
mailing list