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

Reply via email to