[GHC] #11120: Missing type representations

[GHC]

#11120: Missing type representations
-------------------------------------+-------------------------------------
        Reporter:  goldfire          |                Owner:
            Type:  bug               |               Status:  new
        Priority:  high              |            Milestone:  8.0.1
       Component:  Compiler          |              Version:  7.11
      Resolution:                    |             Keywords:
Operating System:  Unknown/Multiple  |         Architecture:
                                     |  Unknown/Multiple
 Type of failure:  None/Unknown      |            Test Case:
      Blocked By:                    |             Blocking:
 Related Tickets:                    |  Differential Rev(s):
       Wiki Page:                    |
-------------------------------------+-------------------------------------

Comment (by goldfire):

 While I'm learning more about this, I stumbled across the following, in
 !TcTypeable:

 {{{#!hs
 mkTyConRepBinds :: TypeableStuff -> TyCon -> LHsBinds Id
 mkTyConRepBinds (dflags, mod_expr, pkg_str, mod_str, tr_datacon,
 trn_datacon) tycon
   = ...
   where
     Fingerprint high low
        | gopt Opt_SuppressUniques dflags = Fingerprint 0 0
        | otherwise                       = fingerprintString hashThis
 }}}

 That looks like the tycon's fingerprint is bogus whenever the module is
 compiled with `-dsuppress-uniques`. But I always understood `-dsuppress-
 uniques` to be a flag used only to control output, and that it should
 affect only the pretty-printer. So I'm very dubious of this code.

 However, in looking through !TcTypeable, I understand why you're worried
 about typerep-generation in GHC.Types: this module looks up the datacons,
 etc., from the type environment. I had blithely assumed that the typerep
 types were truly wired in, in all their glory, making the lookup
 unnecessary. Looking them up never even occurred to me.

 So: Is it better to
 1. look them up, forgo wiring in all the details, and have special-casing
 around GHC.Prim and GHC.Types? or
 2. wire them in fully, but then have a much simpler story around GHC.Types
 and GHC.Prim.

 But now at least I understand what the tradeoff is (I think).

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