[GHC] #12088: Promote data family instance constructors

[GHC]

#12088: Promote data family instance constructors
-------------------------------------+-------------------------------------
        Reporter:  alexvieth         |                Owner:
            Type:  feature request   |               Status:  new
        Priority:  normal            |            Milestone:
       Component:  Compiler (Type    |              Version:  8.1
  checker)                           |
      Resolution:                    |             Keywords:  TypeInType
Operating System:  Unknown/Multiple  |         Architecture:
 Type of failure:  GHC rejects       |  Unknown/Multiple
  valid program                      |            Test Case:
      Blocked By:                    |             Blocking:
 Related Tickets:  #11348            |  Differential Rev(s):  Phab:D2272
       Wiki Page:                    |
-------------------------------------+-------------------------------------

Comment (by alexvieth):

 > Alex suggests adding a potentially large number of extra edges, and
 thene doing standard SCC. But that seems a bit artifical, and I don't
 think it's easy to construct precisely the right extra edges.

 Yes, there could be a lot of extra edges: at most the number of
 `InstDecl`s multiplied by the number of `TyClDecl`s. Computing them also
 requires a dfs for every `TyClDecl`. Compiler performance isn't so great
 even without this change, so we should be careful.

 I'm fairly certain that these are precisely the right extra edges.

   - If `a > b` in the original graph, then `a > b` in the augmented graph,
 because edges are never removed.
   - The SCCs of the original are the same as in the augmented graph: an
 edge is added from `a` to `b` only if there's no path from `b` to `a` (on
 the graph including the other artificial edges).

 > Instances can't be mutually recursive, so singletons are what we need.

 Do you mean that if an instance appears in a cyclic group, the program
 will definitely be rejected? If this is true, then your approach is
 viable, but we need to get the right error message. Perhaps the simplest
 way to do that is to continue using the existing mechanism brought about
 by `tcTyClGroup` (which my patch does), but this would demand that we give
 the `InstDecl`s in their cyclic groups should they arise.

--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12088#comment:6>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler