[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):

 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