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 dependency on "base" in the TemplatHaskell generated code would then also need to be dynamic, allowing the two versions of base to coexist without conflict, both in turn depdent on a common version of the GHC internal libraries. This would of course somewhat complicate binary distributions, but that should be manageable. Perhaps there are less invasive (more clever) solutions? -- Viktor