#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 goldfire): Replying to [comment:38 owst]:
Replying to [comment:37 goldfire]:
In particular, GHC already does dependency analysis and chunking, and it would be terribly wrong not to have splicy things depend on everything else in the declaration group.
I can't actually see that this is true for ''untyped'' splices!
I was referring to [https://github.com/ghc/ghc/blob/master/compiler/rename/RnBinds.hs#L293 this], which is about dependency analysis on bindings in general, not on splices.
Perhaps the obvious question is: is there a particular reason to run
untyped splices in the renamer vs the typechecker? See [wiki:TemplateHaskell/BlogPostChanges]. Splices used to be run in 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). So we seem to be a bit stuck: * Properly checking for mutual recursion requires that splices be run in the renamer. * The use of `reify` as proposed here requires that splices be run in the typechecker. We clearly can't have both. (Note that running the splices twice or something silly like that doesn't solve the problem, as the `reify` calls in the first run will fail.) I'm quite loathe to introduce something like `$$$(...)` to mean an-untyped-splice-that-runs-in-the-typechecker. But I could see having a `-frun-splices-in-typechecker` flag that solves this ticket but breaks #4364; users would just choose which behavior they prefer. (Yes, yes, I know: it would be nice to control this per-splice. Perhaps that would be better.) The downside to this approach is that it means duplicating much of the infrastructure that runs the splices. How bad a burden is this? Hard to know without implementing it. One potential problem: we really can't run ''pattern'' splices during type-checking, as they bring names into scope. So they would be exempted from the new behavior, beguiling users into perpetuity. (Red herring alert: Much of [wiki:TemplateHaskell/BlogPostChanges#Toostronglytyped] talks about the need to run ''quotes'' in the renamer. Anything discussed here would not change that behavior. This is only about ''splices''.) I'm increasingly worried about the power-to-weight ratio of this proposal. Recall that "weight" has two distinct components: 1. The amount of code (both lines and complexity) that this brings, which must be maintained forever. 2. The amount of cognitive burden this feature places on users trying to understand Template Haskell, which would now have two different modes of operation, both with very subtle, hard-to-predict consequences. I'm certainly not saying "no" to the proposal. But I, personally, would need convincing before agreeing to merge. A rising chorus of voices saying "I need this feature in order to use Haskell more successfully for my business or research" tends to be quite convincing. Or perhaps I've entirely mischaracterized the problem and there is an easier way to do all this. That would make me happy. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9813#comment:39 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler