Gergo I'm not close enough to this to have a well-formed opinion, but it looks like a good question to me, esp if the new dependence on TH is optional.
Would you like to transfer the text into a GHC ticket? Simon On Wed, 12 Jul 2023 at 04:40, Gergő Érdi <ge...@erdi.hu> wrote: > 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 > _______________________________________________ > ghc-devs mailing list > ghc-devs@haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
