A recent commit 983ce55815f2dd57f84ee86eee97febf7d80b470 starts using TemplateHaskellQuotes in the GHC codebase. It seems this is at odds with using GHC as a library, a la ghc-lib.

 

The `ghc-lib` approach is to basically take the module hierarchy from the `compiler/` subtree, and compile it as a completely vanilla Haskell library, with no direct attachment to the host GHC version. This enables using e.g. GHC 9.4 to compile a program using the GHC 9.6 API, and so on. In particular, it also makes it very easy to apply patches to the version of GHC used as a library, since in this setup it doesn’t need to be able to bootstrap.

 

So what is the problem with using TemplateHaskellQuotes? The problem is the dependency on the template-haskell package. When a module inside GHC-as-a-library containing TH quotes is compiled, the quotes are translated into applications of the constructors defined by the *host* GHC’s TH package. But because GHC is tightly coupled to the TH support library, GHC-as-a-library needs to ship with its own internal version of the library. So the code that tries to process the results of these quotes is using the *target* GHC’s TH definitions. And that leads to a conflict: code like

 

leftName :: Namel

leftName = ‘Left

is now a type mismatch between the type of `’Left` being template-haskell-2.19.0.0:Language.Haskell.TH.Syntax.Name (example when using GHC 9.4.5 as the host) and the type of `leftName` being ghc-lib-9.9.20230712:Language.Haskell.TH.Syntax.Name (example when the target version is built from recent `master`).

 

Currently, `ghc-lib-gen` has a pre-processing step on the GHC source tree that replaces these quotations with applications containing direct references to the target TH constructors: https://github.com/digital-asset/ghc-lib/blob/ab01fb2b4d1e3a9338390e9c10ccd769bbf37aeb/ghc-lib-gen/src/Ghclibgen.hs#L419-L467 but I am worried that this is very fragile.

 

So any ideas on how to tackle this situation better?

 

Thanks,

            Gergo