[GHC] #652: Have a single Data.Typeable hash table in GHCi

[GHC]

#652: Have a single Data.Typeable hash table in GHCi
-------------------------------+--------------------------------------------
  Reporter:  simonmar          |          Owner:         
      Type:  task              |         Status:  new    
  Priority:  normal            |      Milestone:  6.6    
 Component:  Runtime System    |        Version:  6.4.1  
  Severity:  normal            |     Resolution:         
  Keywords:                    |             Os:  Unknown
Difficulty:  Moderate (1 day)  |   Architecture:  Unknown
-------------------------------+--------------------------------------------
Old description:

> The hash table used by {{{Data.Typeable}}} is declared as a top-level
> IORef.  This means in GHCi, there will be two {{{Data.Typeable}}} hash
> tables: one in the dynamically-loaded base package, and one in the
> statically-linked GHCi binary.  Therefore Dyanmics created in one world
> are incompatible with the other world.
>
> We have a hack to make sure the two hash tables don't use the same
> uniques, so at least a {{{TypeRep}}} created in one world will ''never''
> compare equal to a {{{TypeRep}}} from the other world (before this hack
> we could different TypeReps bogusly claiming to be equal).  However, we
> would like them to compare equal when they are equal.
>
> This implies that the packages in use in both world must be compatible
> (preferably identical).  This is because when a {{{TypeRep}}} compares
> equal, we must be sure that the value has the representation we expect.
> Fortunately this is the case in a stage2 GHC.
>
> We should store a ptr ({{{StablePtr}}}?) to the hash table in an RTS
> global, so that there is only one per runtime instance.

New description:

 The hash table used by {{{Data.Typeable}}} is declared as a top-level
 IORef.  This means in GHCi, there will be two {{{Data.Typeable}}} hash
 tables: one in the dynamically-loaded base package, and one in the
 statically-linked GHCi binary.  Therefore Dyanmics created in one world
 are incompatible with the other world.

 We have a hack to make sure the two hash tables don't use the same
 uniques, so at least a {{{TypeRep}}} created in one world will ''never''
 compare equal to a {{{TypeRep}}} from the other world (before this hack we
 could different {{{TypeRep}}}s bogusly claiming to be equal).  However, we
 would like them to compare equal when they are equal.

 This implies that the packages in use in both world must be compatible
 (preferably identical).  This is because when a {{{TypeRep}}} compares
 equal, we must be sure that the value has the representation we expect.
 Fortunately this is the case in a stage2 GHC.

 We should store a ptr ({{{StablePtr}}}?) to the hash table in an RTS
 global, so that there is only one per runtime instance.

-- 
Ticket URL: <http://cvs.haskell.org/trac/ghc/ticket/652>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler