#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): Replying to [comment:2 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.
Perhaps I'm being dense, but why is this problematic? What panic or other undesirable situation will arise? To be clear: I'm proposing to keep `TyCon` and `Module` and such in `GHC.Types`. But also to put the representations for things defined in `GHC.Types` in `GHC.Types`.
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`,
These are already in `GHC.Types`.
and move the other types (eg `Float`, `Double`) out, so that their type-reps *can* be derived by the normal mechanism.
That seems possible. But I don't think it's necessary, as I've explained above.
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.
This isn't holding me up. I just had to shuffle a bunch of `GHC.Types` and `GHC.Prim` stuff around and wanted to do it right, so I had to understand the `Typeable` stuff. And that led to questions.
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`? No. I want definitions in `GHC.Prim` to depend on `TyCon` and friends, which would remain in `GHC.Types`. This is highly bizarre. But it doesn't seem to break anything. And indeed I have this in my branch (`TYPE` is in `GHC.Prim` but `Levity` is in `GHC.Types`) and nothing complains.
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.
Yes, my proposal means hard-coding `TyCon`s for `TYPE` and `#` (the only lifted types left in `GHC.Prim` in my branch). These would be `Id`s in `MkId` presumably.
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.
`mkGhcTypesTyCon` uses `GHC.Types` as the module whenever it's used. But sometimes it's for `GHC.Prim` types, not `GHC.Types` types.
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. But isn't the fingerprint Very Important? As in: don't we rely critically on fingerprints being unique when doing type comparison? If I understand this correctly, the current implementation means that `-dsuppress-uniques` makes the whole `Typeable` story unsound. And `-dsuppress-uniques` is meant to be a pretty-printing flag. To reduce testsuite wibbles, we should just add something to the post- processor we already have. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/11120#comment:3 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler