[GHC] #7788: Recursive type family causes <<loop>>

[GHC]

#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