Next steps forward for a stable Template Haskell

[Matthew Pickering]

Hi Teo, I went back and read
https://gitlab.haskell.org/ghc/ghc/-/merge_requests/13297

I think my comment is a very good summary there. Which I will paste into
this thread.

```

Why are these packages not re-installable?

   1.

   If you are not using the internal interpreter (or dynamic loading at
   all), then you are free to reinstall any package as long as the resulting
   package database contains a unit for each of the wired in unit ids which
   exports the relevant wired-in definitions.
   2.

   If you are using template-haskell and the internal interpreter, then
   your program must link against exactly the same version of template-haskell
   (and dependencies) that the
   3.

   If you are using plugins, then your program must link against exactly
   the same version of ghc library (and dependencies)

** Cabal simplifies all of these situations by refusing to reinstall
certain packages and always using the global package database **

   1. Cabal refuses to reinstall wired in units and always uses the global
   package database, therefore the relevant unit is always available with the
   correct ABI.
   2. Cabal refuses to reinstall template-haskell, which forces it to be
   taken from the global package database, which ensures it is the same
   version as the compiler is linked against.
   3. Cabal refuses to reinstall ghc library, which forces it to be taken
   from the global package database, which ensures the same version of the
   library is linked against.

Therefore I don't think it's accurate for the compiler to advertise in
particular which packages are "not reinstallable", as that is not a
property of the compiler itself.

There is no conceptual barrier to the situation where you want to use
template-haskell or ghc library in a situation where you don't want or need
to dynamically load code into the running process. In this situation, it
would be perfectly permissible to reinstall it and use it in your program.
The issue comes that Cabal doesn't allow you to express the constraint that
the version of template-haskell you depend on needs to be fixed to the one
the compiler is built against. As such, it has to be pessimistic and never
reinstall template-haskell or ghc, but against, not an issue in particular
with GHC.

** Cabal can not express the constraint that a library must be the same
version as the one the build compiler is built against **

```

Your point is that

* GHC should advertise to Cabal which (template-haskell, ghc) unit it links
against. Then cabal should ensure that if TemplateHaskell/plugins are used
then it should enforce in the build plan that this version of
`template-haskell`/`ghc` is picked.

My point was

* GHC can only advertise a unit id, it wasn't clear to me about how to map
this information into the cabal solver.

I suppose we will have the assumption that if GHC advertises it is linked
against a specific unit id, then that unit will be in a global package
database. Cabal already reads the global package database.

Perhaps the only thing we need to add to the cabal solver is the ability to
express a constraint that you depend on a precise unit-id. Then when
cabal-install starts the solver it can query GHC to find the unit-ids which
need to be fixed, and feed those constraints into the solver. Then if users
are feeling very brave, they can turn off this behaviour..

Thinking aloud here..

Matt






On Wed, Apr 2, 2025 at 6:26 PM Teo Camarasu <teofilcamarasu at gmail.com>
wrote:

> Hi folks,
>
> At Tuesday's GHC devs meeting, we talked about having a discussion about
> template-haskell stability. I've jotted down some notes to help focus our
> future discussion. It's mostly just a list of what I take to be the next
> most important issues to tackle, and some details about each.
>
>
> https://docs.google.com/document/d/1gui1YXOvrNihR3NpXuMVCKV3lTkKPL8y_HDRjbZyRxk/edit?usp=sharing
>
> Cheers,
> Teo
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20250408/5ad6980b/attachment.html>