#11120: Missing type representations -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: closed Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1774 Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari):
That's only because we do mkTypeableBinds on a group by group basis.
That might also mean that we could generate type representations for all types in `GHC.Types` instead of the weird stuff that happens now, with
That is a fair point. I can give this a try. them being manually defined elsewhere Actually since my refactoring there is no oddness in the handling of `GHC.Types`; since `TyCon`, et al. are wired-in we allow the usual codepath to generate the representations for types defined in this module. The only oddness at this point is the handling of `GHC.Prim`, which needs to have its representations injected into `GHC.Types`. Performing the refactoring you mention above would allow us to retain the consistent handling of `GHC.Types` while un-wiring `TyCon` and friends. Currently type constructor representations are produced by `tcAddImplicits`. Should we move the entire `tcAddImplicits` step until after all groups have been typechecked or only extract the typeable handling? -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/11120#comment:40 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler