[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 simonpj):

 Excellent example!

 It seems clear that there is going to be no reasonable "always-right"
 solution to this.

 Moreover, here is another horrible example
 {{{
 data T1 = MkT1 (...something requiring IA...)
 data T2 = MkT2 (...something requiring IB...)
 type instance F1 Int = ...T2...    -- IA
 type instance F2 Int = ...T1...    -- IB
 }}}
 Here F1 and F2 are supposed to be like Open1 and Open2 in your example;
 they must be processed in the right order.

 But T1 and T2 appear to be entirely independent of each other, so SCC
 analysis will put them in some arbitray order; and that order in turn
 determines which of IA and IB can be processed because IA mentions T2 and
 IB mentions T1.

 So only one ordering of the apparently un-ordered T1, T2 will work.

 Can you turn that sketch into a concrete example?  It's even more horrible
 than yours because the invisible ordering of instances seems to force an
 equally-invisible ordering of the data declarations too.  Sigh.

 I'm not sure what to do.

 The only simple, predictable thing I can think of is this:

  * Perform SCC analysis on each group of data/type/class/data-instance
 decls that lie between successive `type instance` decls.
  * Otherwise process the file in the order writtten, from top to bottom.

 That is, divide the file into segments, delimited by `type instance`
 decls.  Process the file top-to-bottom, one segment at a time, processing
 the `type instance` decls in the order they are written.

 That's simple, easy to specify, and easy to implement.  Where there are no
 `type instance` decls, we get full SCC analysis across the entire module.
 The big disadvantage is that where you have a forward reference, kind
 checking will just fail:
 {{{
 data T = MkT S  -- Forward reference
 type instance F Int = Bool
 data S = MkS Int
 }}}
 That is pretty bad.  Can you think of an alternative rule?  The goal is
 NOT to be as clever as possible.  THe goal is to be as stupid,
 straightforward, and predictable as possible, even if that might mean a
 little manual labour on the part of the programmer.

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