Usage of Template Haskell quotes in GHC source tree vs. usage of GHC as a library

Gergő Érdi gergo at erdi.hu
Wed Jul 12 03:40:25 UTC 2023


Hi,



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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20230712/1ec05b27/attachment.html>


More information about the ghc-devs mailing list