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