Data.Dynamic and dynamically loaded code
simonmar at microsoft.com
Mon Jun 14 10:56:09 EDT 2004
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.
> -- the current solution solves the immediate problem, which is
> -- 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
More information about the Glasgow-haskell-users