john at repetae.net
Mon Mar 7 19:04:47 EST 2005
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
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
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 Meacham - ⑆repetae.net⑆john⑈
More information about the Libraries