#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