Data.Dynamic

[Simon Peyton-Jones]

Here's a rather long-ago message from John Meacham that I failed to reply to.

Simon M and I talked about this.  While we aren’t rabidly against hashTypeRep (with an IO type), if you are going to have an IO type you might as well have typeRepId :: TypeRep -> IO Int, which gives a unique Int, distinct for each TypeRep.

But beyond that, it's very inconvenient to have to do IO.  One way to sidestep the determinacy issue is to provide TypeRepMap as part of the interface to TypeRep

	data TypeRepMap a
	insertTR :: TypeRepMap a -> TypeRep -> a -> TypeRepMap a
	union, get elts, etc etc

The downside is that it needs a pretty big interface to be useful.  The upside is that it can be purely functional.

My suggestion would be for someone to bite the bullet, design the interface, and implement it efficiently (not difficult).  Though I hate offering such a big interface, TypeReps are useful, and should be efficient, and this is a way to get that without compromising with determinacy.

So	a) do others agree
	b) any volunteers to do the legwork?

Simon

| -----Original Message-----
| From: libraries-bounces at haskell.org [mailto:libraries-bounces at haskell.org] On Behalf Of John
| Meacham
| Sent: 08 March 2005 00:05
| To: libraries at haskell.org
| Subject: Re: Data.Dynamic
| 
| 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⑈
| _______________________________________________
| Libraries mailing list
| Libraries at haskell.org
| http://www.haskell.org/mailman/listinfo/libraries