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 _______________________________________________ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users