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