On 23 June 2004 03:53, John Meacham wrote:
Yeah, i forgot about the GC moving things around. actually, if the GC
could be coaxed to move things around, but never change the relative
order of IORefs (like a compacting collector), then the address could
still be used for Ord and Eq.
This is a
G'day all.
Quoting John Meacham [EMAIL PROTECTED]:
would it be possible to provide an Ord instance for (IORef a)?
It would, although then someone else would just want a hashable instance.
Sounds to me like it might be worth coming up with a general IORef (and
STRef) wrapper.
Until then, this
G'day all.
Quoting [EMAIL PROTECTED]:
Until then, this is what I use.
Second time lucky.
Cheers,
Andrew Bromage-
-- |
-- Module : Data.IOStableRef
-- Copyright : (c) Andrew Bromage 2002
-- License :
| 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
On 22-Jun-2004, Simon Peyton-Jones [EMAIL PROTECTED] wrote:
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
G'day all.
Quoting Fergus Henderson [EMAIL PROTECTED]:
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
