#1012: ghc panic with mutually recursive modules and template haskell -------------------------------------+------------------------------------ Reporter: guest | Owner: Type: bug | Status: new Priority: lowest | Milestone: 7.6.2 Component: Template Haskell | Version: 6.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: TH_import_loop | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by goldfire): I just got bitten by this, and I don't see a clean reorganization. While I agree that this should be "lowest" priority, I thought I'd document my real-life use case: The singletons library generates a fair amount of code using TH. In particular, it produces instances for classes, type families, and data families. Accordingly, the TH code needs to know the names of these classes and families, and the names of the class members. In the main module of the library, I want to use the TH code to produce lots of instances for datatypes exported from base (`Bool`, `Maybe`, `()`, ...). I don't want these instances to be orphans. So, I'm stuck. I'll illustrate further with some code: Module `Data.Singletons` (boot): {{{ data family Sing (a :: k) }}} Module `Data.Singletons.Singletons`: {{{ import {-# SOURCE #-} Data.Singletons singName :: Name singName = ''Sing genSingletons :: [Name] -> Q [Dec] genSingletons = ... }}} Module `Data.Singletons`: {{{ import Data.Singletons.Singletons data family Sing (a :: k) $(genSingletons [''Bool, ''Maybe, ''Either, ''[]]) }}} This all seems quite sensible to me, yet GHC can't do it. It seems I have several bad options: 1) allow orphans, defining the `Sing` family in a different module than its instances; 2) hand-write the instances I want, avoiding the loop; or 3) use `mkName` to create the names. I'm going to do (3), but it feels dirty and fragile. Note: I do see why calling a function at compile time that is defined in a module in a mutually-recursive group with the calling module could be very bad. But, I'm not quite doing that here. That said, I don't see an easy way to allow what I want, prohibit the bad behavior, and not pollute the syntax and implementation of it all. The reason for this comment is just to document a case where I'm a little hamstrung by this missing behavior, not that I really want resources dedicated to finding a fix here. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/1012#comment:27 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler