Data.Dynamic and dynamically loaded code

[Simon Marlow]

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.

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.

Cheers,
	Simon