Data.Dynamic and dynamically loaded code

[Donald Bruce Stewart]

simonmar:
> On 10 June 2004 05:32, Donald Bruce Stewart wrote:
> 
> > The problem appears to be in the hash keys of the type representation
> > used to compare to types for equality. A dynamic value in the
> > (statically compiled) application never has the same key as its
> > equivalent type in the dynamically loaded code.  The type in the
> > dynamically-loaded plugin code is never recognised as having the same
> > type as in the application (static) code.
> > 
> > The following comment from Data.Typeable seems to be relevant:
> > 
> >     -- In GHC we use the RTS's genSym function to get a new unique,
> >     -- because in GHCi we might have two copies of the Data.Typeable
> >     -- library running (one in the compiler and one in the running
> >     -- program), and we need to make sure they don't share any keys.
> >     --
> >     -- This is really a hack.  A better solution would be to
> >     centralise the -- whole mutable state used by this module, i.e.
> >     both hashtables.
> > But 
> >     -- the current solution solves the immediate problem, which is
> > that 
> >     -- dynamics generated in one world with one type were erroneously
> >     -- being recognised by the other world as having a different type.
> 
> This is exactly the problem.  To fix it, you need to implement the
> suggestion from the comment: i.e. somehow make it so that there is only
> one copy of the hash table rather than two.  You could do this by
> keeping the hash table in a variable in the RTS, perhaps.

Ok! That's what I'll do.
  
> I don't know why you get differing String representation of types,
> though.  It doesn't have anything to do with Core types, I'm pretty
> sure.

I've fixed this particular issue by reimplementing the Eq for TypeRep
and TyCon in Data.Typeable to use the String rep for equality of
TypeReps, rather than using show to compare two TypeReps, in
Dynamic.fromDyn. Fixing Eq at a lower level than Dynamic seemed to do
the trick. Still not sure why using show in fromDyn caused the two
different representations, though.

-- Don