[GHC] #9858: Typeable instances should be kind-aware

[GHC]

#9858: Typeable instances should be kind-aware
-------------------------------------+-------------------------------------
        Reporter:  dreixel           |                Owner:
            Type:  bug               |               Status:  closed
        Priority:  highest           |            Milestone:  7.10.2
       Component:  Compiler          |              Version:  7.9
      Resolution:  fixed             |             Keywords:
Operating System:  Unknown/Multiple  |         Architecture:
                                     |  Unknown/Multiple
 Type of failure:  None/Unknown      |            Test Case:
                                     |  typecheck/should_fail/T9858a,b,c;
                                     |  should_run/T9858b
      Blocked By:                    |             Blocking:
 Related Tickets:                    |  Differential Rev(s):  Phab:D652
-------------------------------------+-------------------------------------

Comment (by Ben Gamari <ben@…>):

 In [changeset:"91c6b1f54aea658b0056caec45655475897f1972/ghc"
 91c6b1f5/ghc]:
 {{{
 #!CommitTicketReference repository="ghc"
 revision="91c6b1f54aea658b0056caec45655475897f1972"
 Generate Typeable info at definition sites

 This is the second attempt at merging D757.

 This patch implements the idea floated in Trac #9858, namely that we
 should generate type-representation information at the data type
 declaration site, rather than when solving a Typeable constraint.

 However, this turned out quite a bit harder than I expected. I still
 think it's the right thing to do, and it's done now, but it was quite
 a struggle.

 See particularly

  * Note [Grand plan for Typeable] in TcTypeable (which is a new module)
  * Note [The overall promotion story] in DataCon (clarifies existing
 stuff)

 The most painful bit was that to generate Typeable instances (ie
 TyConRepName bindings) for every TyCon is tricky for types in ghc-prim
 etc:

  * We need to have enough data types around to *define* a TyCon
  * Many of these types are wired-in

 Also, to minimise the code generated for each data type, I wanted to
 generate pure data, not CAFs with unpackCString# stuff floating about.

 Performance
 ~~~~~~~~~~~
 Three perf/compiler tests start to allocate quite a bit more. This isn't
 surprising, because they all allocate zillions of data types, with
 practically no other code, esp. T1969

  * T1969:    GHC allocates 19% more
  * T4801:    GHC allocates 13% more
  * T5321FD:  GHC allocates 13% more
  * T9675:    GHC allocates 11% more
  * T783:     GHC allocates 11% more
  * T5642:    GHC allocates 10% more

 I'm treating this as acceptable. The payoff comes in Typeable-heavy
 code.

 Remaining to do
 ~~~~~~~~~~~~~~~

  * I think that "TyCon" and "Module" are over-generic names to use for
    the runtime type representations used in GHC.Typeable. Better might
 be
    "TrTyCon" and "TrModule". But I have not yet done this

  * Add more info the the "TyCon" e.g. source location where it was
    defined

  * Use the new "Module" type to help with Trac Trac #10068

  * It would be possible to generate TyConRepName (ie Typeable
    instances) selectively rather than all the time. We'd need to persist
    the information in interface files. Lacking a motivating reason I
 have
    not done this, but it would not be difficult.

 Refactoring
 ~~~~~~~~~~~
 As is so often the case, I ended up refactoring more than I intended.
 In particular

  * In TyCon, a type *family* (whether type or data) is repesented by a
    FamilyTyCon
      * a algebraic data type (including data/newtype instances) is
        represented by AlgTyCon This wasn't true before; a data family
        was represented as an AlgTyCon. There are some corresponding
        changes in IfaceSyn.

      * Also get rid of the (unhelpfully named) tyConParent.

  * In TyCon define 'Promoted', isomorphic to Maybe, used when things are
    optionally promoted; and use it elsewhere in GHC.

  * Cleanup handling of knownKeyNames

  * Each TyCon, including promoted TyCons, contains its TyConRepName, if
    it has one. This is, in effect, the name of its Typeable instance.

 Updates haddock submodule

 Test Plan: Let Harbormaster validate

 Reviewers: austin, hvr, goldfire

 Subscribers: goldfire, thomie

 Differential Revision: https://phabricator.haskell.org/D1404

 GHC Trac Issues: #9858
 }}}

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