#14030: Implement the "Derive Lift instances for data types in template-haskell" proposal -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: RyanGlScott Type: task | Status: new Priority: normal | Milestone: 8.8.1 Component: Template Haskell | Version: 8.3 Resolution: | Keywords: deriving Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): At one point in time (a release of GHC or two ago), I attempted to implement this, but ran into interface file-related issues. Unfortunately, I no longer have the exact errors in front of me, but I recall that there was some difficulty due to the fact that: 1. We were deriving `Lift` instances in `Language.Haskell.TH.Syntax` 2. The derived `Lift` code references functions from `Language.Haskell.TH.Lib.Internal` 3. Because `Language.Haskell.TH.Lib.Internal` imports `Language.Haskell.TH.Syntax`, there were (seemingly) some issues with import cycles That being said, I just tried implementing this afresh with GHC 8.6.2 as my bootstrapping compiler, and I did not hit any issues at all! This is quite strange, and I'm somewhat paranoid that there //is// an issue lurking underneath the surface that I just haven't exposed yet. While typing this out, I realized one thing. I think the last time I tried this, I might have been using GHC 8.2.2 as my bootstrapping compiler. There is a notable difference between 8.2.2 and future major releases: 8.2.2 does //not// have `Language.Haskell.TH.Lib.Internal` (it wouldn't be until 8.4 that that would come into existence). I think GHC might have been confused because the `DeriveLift`-generated code that the bootstrapping compiler (8.2.2) generated mentioned things from `Language.Haskell.TH.Lib`, but the stage-1 compiler generated `DeriveLift` code that mentioned `Language.Haskell.TH.Lib.Internal`. If that's the case, then that would explain why I can't reproduce the issue now (with 8.6.2). Still, this has me a bit worried that what we're doing here is a bit fragile, and that perhaps moving functions from `Language.Haskell.TH.Lib.Internal` to some other, hypothetical module in the future might cause this issue to surface once more... -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/14030#comment:6 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler