RE: [Haskell-cafe] Ord (IORef a)?
| From: John Meacham | would it be possible to provide an Ord instance for (IORef a)? For | things like loop detection, one may need to make many IORef comparasions | and being able to use an efficient set would be a really big win. | | Since IORefs are created in the IO monad, the actual order can be | arbitrary without breaking referential transparency (as long as it | doesn't change over the lifetime of the IORef.) I think that'd be entirely reasonable. Two runs of the same program might give observably different behaviour wrt Ord, but that's ok because the refs are allocates in the monad, as you say. There is an efficiency cost though. Each IORef would need to have an extra field, to record its allocation ID. (Address is not enough -- the garbage collector can mangle them.) My own view is that this is fine -- IORefs shouldn't be in your inner loop, so an extra word in each is no big deal. Unless there are views to the contrary, I'd be happy to see this in GHC. Simon
On 22-Jun-2004, Simon Peyton-Jones
My own view is that this is fine -- IORefs shouldn't be in your inner loop, so an extra word in each is no big deal.
I find that attitude rather extraordinary and I do not agree. For some applications, IORefs may well be a major contributor to memory usage, and increasing the amount of space that they take up may significantly decrease locality and hence performance. -- Fergus J. Henderson | "I have always known that the pursuit Galois Connections, Inc. | of excellence is a lethal habit" Phone: +1 503 626 6616 | -- the last words of T. S. Garp.
G'day all.
Quoting Fergus Henderson
I find that attitude rather extraordinary and I do not agree.
Me too. I've written more than one Haskell program where hash consing is part of an "inner loop". For this applciation the data structures weren't that big, but I can easily think of a few applications for which it would be. Cheers, Andrew Bromage
Simon Peyton-Jones wrote:
... There is an efficiency cost though. Each IORef would need to have an extra field, to record its allocation ID. (Address is not enough -- the garbage collector can mangle them.)
My own view is that this is fine -- IORefs shouldn't be in your inner loop, so an extra word in each is no big deal. Unless there are views to the contrary, I'd be happy to see this in GHC.
It's worth noting at this point that the Java world has developed a nice, big bag of tricks for language implementors to use to solve exactly this problem. Somehow, they make it work even for the stuff which *is* in the inner loop. :-) -Jan
participants (4)
-
ajb＠spamcop.net -
Fergus Henderson -
Jan-Willem Maessen - Sun Labs East -
Simon Peyton-Jones