Thanks both! I've updated the doc and replied to your comments Simon. I'll also update the wiki page soon. Thanks for summarising Matt! I've copied over your email into the doc. I'll also post your suggestion in the cabal ticket. Cheers, Teo On Tue, Apr 8, 2025 at 10:24 AM Matthew Pickering < matthewtpickering@gmail.com> wrote:

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 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_HDRjbZy...

Cheers, Teo _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs