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
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
