#7788: Recursive type family causes <<loop>> -------------------------------------+------------------------------------- Reporter: shachaf | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler (Type | Version: 7.6.2 checker) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: Incorrect result | Test Case: at runtime | Blocking: Blocked By: | Differential Revisions: Related Tickets: #8550 | -------------------------------------+------------------------------------- Comment (by goldfire): Just took a quick look at this, as I was in the area. This will take some plumbing to implement right, sadly. The problem is that the type family reduction happens in the bowels of the flattening algorithm. To do this right, we need to update the `CtLoc` of the relevant constraint, but there's no good way to do that from the middle of the flattener. Two ways forward: 1. Install the plumbing. I vote that this should be a new `FlatM` monad (built on `TcS`) that allows updating of the `CtLoc` currently stored in the `FlattenEnv`. `FlatM` would gather up the `FlattenEnv` stuff, the `runFlatten` stuff, and this new type-family-depth-counting stuff. Seems like enough stuff to make it a new structure. 2. Have a local counter just for the new, eager type family reduction. We have access to `DynFlags`, of course, so we can check if the number of eager reductions is more than requested. We can even add the number of eager reductions to the number of reductions done previously. What we can't do is record the number of eager reductions. So, if the stack depth were 200, then this plan (2) would allow, say, 190 eager reductions at one go, then some other solving, and then another 190 eager reductions, and then some solving, and so on. The depth is still bounded, but it makes it nigh impossible for a programmer to relate their choice of `-ftype- function-depth` to GHC's behavior, as it all depends on where the reduction takes place. Thoughts? Still no promises on getting to this for real before March, I'm afraid, especially for option 1. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/7788#comment:13 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler