Skip to content

DeriveLift leads to undeclared dependencies on Language.Haskell.TH.Lib

Modules in containers use DeriveLift in order to give Lift instances for the data types. This is problematic for multi-component sessions which involve loading containers and template-haskell into the same session because

  • Lift comes from Language.Haskell.TH.Syntax
  • DeriveLift used identifiers from Language.Haskell.TH.Lib.Internal

Therefore the modules add an import on Language.Haskell.TH.Syntax (in order to import Lift) but no dependency is recorded between the module and Language.Haskell.TH.Lib.Internal. However, we need to compile the Internal module before the module in containers as the desugared code for DeriveLift depends on the combinators defined in this module.

Can we fix this in GHC? How about adding these edges if a module enables DeriveLift? This option is precluded because -XDeriveLift is included in Haskell2021 so almost all modules which exhibit a new dependency on template-haskell library without using it. The most straightforward but ugly solution is to explicitly add these edges to the build graph. Most projects will not encounter this issue because they will not be compiled in the same session as the template-haskell package.

This has already caused a couple of build system issues in GHC, see !9049 (closed) for example.

Note that

  • This only affects hard-core GHC developers, who are building GHC itself.
  • Hadrian (used by the aforementioned developers) is clever enough to know the dependency of a module M of package A, on a module X of a different package B. So we can start building package A before finishing building package B.
Edited by Simon Peyton Jones
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information