Viktor Dukhovni <ietf-d...@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
signature.asc
Description: PGP signature
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs