unsafePtrCompare, anybody?

[Leon Smith]

> I can't think of a way to use unsafePtrCompare safely :-)  The relative
> ordering of objects isn't guaranteed to be stable under GC.
>
> Cheers,
> 	Simon

Doh,  that would throw a monkey wrench into things, wouldn't it?   I know of 
compacting GC algorithms, but I didn't consider that GHC might be using one.  
At least I am now more enlightened on the inner workings of the magic beast...

I've considered many of the other implementation options, but as it isn't 
essential to the working of the compiler,  it hasn't been a priority yet.  It 
simply struck me that this would be a particularly quick and easy way to 
implement reasonably good atom tables, only requiring a newtype declaration 
and a few very simple function definitions.   

Thanks to Simon for saving me from reinventing the wheel.   The libraries 
mentioned here should prove to be quite useful.  

One's intuition would suggest that you could be safely implement mkAtom 
without wrapping it in a IO monad.   After all, at least at a abstract level, 
an atom table is referentially transparent.  The library documentation says 
that lack of side effects and environmental independance is sufficent to 
order for uses of unsafePerformIO to be safe.  Is there a exact (or at least 
better) criterion for safety?   

"unsafePerformIO" is used in the implementation of mkFastString, so how is 
it's side effects "safe".   I experimented with unsafePerformIO with my Atom 
table, but I could not get tthe code to work properly.

best,
leon