I was referring to [https://github.com/ghc/ghc/blob/master/compiler/rename/RnBinds.hs#L293
See [wiki:TemplateHaskell/BlogPostChanges]. Splices used to be run in
So we seem to be a bit stuck:
[...] I'm increasingly worried about the power-to-weight ratio of this
#9813: Error when reifying type constructor -------------------------------------+------------------------------------- Reporter: owst | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1899 Wiki Page: | -------------------------------------+------------------------------------- Comment (by owst): Replying to [comment:39 goldfire]: this], which is about dependency analysis on bindings in general, not on splices. Aha! Incidentally, the line linked is never reached for the failing testcase in the original report, since the line above it is where the splice is renamed, and the `reify` call fails. the typechecker. But that caused #4364. And, sadly, I don't know a way to solve #4364 and the current ticket. The plan from comment:32 implicitly assumes that deciding that two declarations are mutually recursive is a conservative choice, and so we can do it even when we're not sure that the declarations are indeed mutually recursive. But #4364 shows us that this is not the case -- mutual recursion is ''not'' conservative for type declarations. And it isn't really for term declarations either: when declarations are mutually recursive, type generalization happens ''after'' checking the whole group, and so making more definitions think that they are mutually recursive potentially reduces that level of polymorphism (don't have an example of this intricate interaction to hand, I'm afraid). Ah yes, a very good reason to move running of splices to the renamer. Thanks for pointing out the relevant ticket! proposal.
I agree, you're absolutely right about the power-to-weight ratio; bother! :-) Oh well, I've tweaked the manual so hopefully there might be a little less confusion about what's going on in this situation (and indeed, a pointer towards the `$(return [])` workaround). I'll try and move onto the next small ticket! Thanks for the discussion on this one, goldfire! -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9813#comment:40 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler