2010/12/5 Tianyi Cui :

Why should they? You can compare them in whatever way you like. And there isn't a natural/inherent sense of total order between types.

I cannot compare then the way I'd like. ;) Consider the following: data BiMap a = BiMap { values :: Map Int a ,indices :: Map a Int } It will serve well for Int's, Bool's and Expr's. Then I decided to store typed Expr's, based on GADTs. Those Expr's contains type indices and it would be natural to classify BiMaps by their type indices and look up in there. If I require type indices to be Typeable, all I need is ordering on TypeRep. Also, I prototyped hypergraph library with hyperedges as types with type family as HList of types denoting labels. There I needed ordering on TypeRep too, again, for efficiency reasons.

Thinking about this there might be one problem: Without having looked further into this I think perfomance might not be as expected. Using unsafePerformIO affects ghc's optimzations, doesn't it? So I wonder if it's a good idea (from a performance point of view) to use this.

2010/12/30 Andreas Baldeau :

...

instance Ord TypeRep where    compare t1 t2 =        compare            (unsafePerformIO (typeRepKey t1))            (unsafePerformIO (typeRepKey t2))

...

typeRepKey :: TypeRep -> IO Int typeRepKey (TypeRep (Key i) _ _) = return i

So the question is, if ghc could transform this to simply compare the keys throwing away unsafePerformIO and return.

On Saturday 01 January 2011 15:07:13, Thomas Davie wrote:

On 1 Jan 2011, at 12:38, Andreas Baldeau wrote:

...

So the question is, if ghc could transform this to simply compare the keys throwing away unsafePerformIO and return.

Wouldn't a much better plan simply be to take typeRepKey out of the IO monad?

I don't think so, it's in IO for a reason:

-- | Returns a unique integer associated with a 'TypeRep'. This can -- be used for making a mapping with TypeReps -- as the keys, for example. It is guaranteed that @t1 == t2@ -- if and only if @typeRepKey t1 == typeRepKey t2@. -- -- It is in the 'IO' monad because the actual value of the key may -- vary from run to run of the program. You should only rely on -- the equality property, not any actual key value. The relative -- ordering of keys has no meaning either. -- typeRepKey :: TypeRep -> IO Int

That also means that an Ord instance based on the keys may change from run to run. It's probably not a problem for applications if it's only used for storing TypeReps in a Map and not for programme logic (if typeOf 'a' < typeOf True then this else that), but it's somewhat fishy nevertheless.

On 13:04 Sat 01 Jan , Felipe Almeida Lessa wrote:

But, if you want to have a strang Ord instance, then why not have a strange unsafeTypeRepKey :: TypeRep -> Int?

Yes, that would be nice. But only if this really helps the compiler with optimising the code. Otherwise one could easily use unsafePerformIO. Andreas