On Mon, Mar 07, 2005 at 12:52:53PM -0000, Simon Peyton-Jones wrote:

but typeRepIndex :: TypeRep -> IO Int looks stranger. It breaks the TypeRep abstraction. Would you care to argue for it?

Mainly the reasons Geore Russell brought up a while ago, fast maps via an compare or Hash on TypeReps are needed for various type-indexed structures. http://www.haskell.org//pipermail/haskell-cafe/2004-November/007734.html We had no consensus on creating an Ord instance, since it could differ between runs so was 'unsafe' in a weak sense, but adding something in IO would be good enough for most applications and would sidestep the whole issue :). Perhaps calling it hashTypeRep :: TypeRep -> IO Int and only guarenteeing the weaker many-to-one semantics of hash functions would be more appropriate and future-safe. Another alternative would be compareTypeRep :: TypeRep -> TypeRep -> IO Ordering but I prefer the hash version. I still think we should have two ordering classes, one for the natural ordering in the prelude, and one for an efficient ordering for creating maps or sets with the side condition that code may not depend on the particular order it gives, just that it is a total order. But that is another discussion :) John -- John Meacham - ⑆repetae.net⑆john⑈