Why can't we re-install the template-haskell package?

[Moritz Angermann]

Hi Ryan, hi Richard,

> My (limited) understanding is that template-haskell is not reinstallable for the same reasons that base and ghc-prim aren't reinstallable: the GHC codebase directly wires in several definitions several functions, types, and data constructors from template-haskell. See THNames [1]. If one were to, say, use GHC 8.6 but install a different version of template-haskell than the one that came bundled with 8.6, then it's almost certain that lots of code in THNames would no longer work, since they could be referencing identifiers that no longer exist (if the new version of template-haskell doesn't have them).

Right, I'm mostly concerned about re-installing the *same* version again.  For the motivation:
template-haskell depends on pretty, deepseq and array.  Let's assume there is some off-by-one issue
in array that only affects my application right now.  Now I'm going to patch my array package, but
if my application depends on template-haskell, I end up with two different array packages in my dependency
tree that are not identical.  What I'd ideally like to do here is to re-install deepseq, pretty and
template-haskell based on my fixed array package.  Now I don't have two different array packeds in my
dependencies anymore; it would however require me to be able to rebuild (the same version) of template-haskell.


> I have to admit I don't have a strong grasp on what "reinstallable" implies. Does a package get the same hash after reinstalling? What could make a package not reinstallable? Why aren't packages reinstallable today? Why isn't ghc-prim reinstallable?

We can't re-install packages that depend on build-time values. The RTS and ghc-prim right now
include files that are generated during the build process and they have no capability on their
own to create those files, as such re-installing them is not possible right now.

> My concern stems from the fact that ghc is interlinked with TH in at least two ways:
> - GHC imports definitions from template-haskell. But this is the same as the way GHC is involved with, say, `base`.
> - GHC also wires in some template-haskell definitions. This is the aspect I am worried about. Is `base` reinstallable? If so, then perhaps template-haskell could be, too.


Now especially with TH I might see an issue when *running/using* TH, as at that point the compiler
and the produces code have to interact.  That is we are compiling splices against a different
template-haskell package than the compiler is built against.  This is where I see *upgrading* (that
is building a newer version of Template Haskell) could be an issue, but I feel I don't fully grasp
why rebuilding the same version should pose an issue.

If we go one step further and use iserv (-fexternal-interpreter) outright, then I think we could just
rebuild iserv against the re-installed template-haskell, and would not even run into the above
mentioned issue. Might this potentially even be allow us to upgrade template-haskell?

Cheers,
 Moritz
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: Message signed with OpenPGP
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190308/5d06757c/attachment.sig>