Reinstallable - base

[Andrei Borzenkov]

 > 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>  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 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/2b0bfe8b/attachment.html>