#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 simonpj):
1. You say (in Note [Grand plan for Typeable]) that there is trouble making the TyCon/Module information for the types in GHC.Types. But what precisely goes wrong? I agree that it seems a bit fishy, but I don't actually see the spot where trouble lurks. Did you try this?
The difficulty is we can't generate the `TyCon` and `Module` for things in `GHC.Types` when `TyCon` and `Module` are not yet defined. The Grand Plan comment says: It's hard to generate the TyCon/Module bindings when the types TyCon and Module aren't yet available; i.e. when compiling GHC.Types Now what we ''could'' do (and it'd probably be a goodea) would be to put * TyCon * Module * Char * List * TrName in `GHC.Types`, and move the other types (eg `Float`, `Double`) out, so that their type-reps *can* be derived by the normal mechanism.
3. Let's assume that we really can't clean up this mess. It still seems that several TyCons are missing from Data.Typeable.Internal. Like promoted nil and cons, and Nat, and Symbol. At the least, we should put a loud comment in the export list of GHC.Types saying that everything defined there must be accompanied by a definition in Data.Typeable.Internal.
You are right. The above might ameliorate the problem. If it'd make your kind-equality work easier by all means do this.
2. Even more bizarre would be putting TyCon/Module info for GHC.Prim stuff (I'm thinking about the super-magical TYPE) right in GHC.Prim.
But currently `TyCon` uses list and `Char`. Do you want to put them in `GHC.Prim`? How would that differ, really, from what we have now. And `TyCon` and `Module` both require actual code, whereas `GHC.Prim` types have no code. To respond to your suggestion more clearly I'd need more info on what you have in mind.
4. `Data.Typeable.Internal` uses `mkGhcTypesTyCon`, which refers to `GHC.Types`
I don't understand the issue here.
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.
Good point. But failing to suppress means that `-ddump-simpl` will show some unique values. Maybe that's ok. It's mainly use to reduce test- suite wobbles. I'm honestly not sure what to do here, but not too bothered either way. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/11120#comment:2 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler