unique identifiers as a separate library

Iavor Diatchki iavor.diatchki at gmail.com
Sun Dec 21 14:05:56 EST 2008


Hello,
I have made the two changes that Simon suggested and uploaded a new
version of the library.   By the way, GHC seemed to work correctly
even without the extra boolean parameter, perhaps it treats
unsafePerformIO specially somehow?  A somewhat related question:  I
ended up using three calls to unsafeInterleaveIO which seems like a
bit much.  Could I have done it in a different way somehow?  This is
what I did:

gen r = do v <- unsafeInterleaveIO (genSym r)
                   ls <- unsafeInterleaveIO (gen r)
                   rs <- unsafeInterleaveIO (gen r)
                   return (Node v ls rs)

Note that a single unsafeInterleaveIO around the whole do block is not
quite right (this is what the code in the other package does) because
this will increment the name as soon as the generator object is
forced, and we want the name to be increment when the name is forced.

-Iavor




On Fri, Dec 19, 2008 at 1:24 AM, Simon Marlow <marlowsd at gmail.com> wrote:
>> Why not depend on this instead?
>>
>> http://hackage.haskell.org/cgi-bin/hackage-scripts/package/value-supply
>
> Looking at the code for this, I'm somewhat suspicious that it actually works
> with GHC:
>
>  -- The extra argument to ``gen'' is passed because without
>  -- it Hugs spots that the recursive calls are the same but does
>  -- not know that unsafePerformIO is unsafe.
>  where gen _ r = Node { supplyValue  = unsafePerformIO (genSym r),
>                         supplyLeft   = gen False r,
>                         supplyRight  = gen True r }
>
> even if that extra Bool argument is enough to fool Hugs, I wouldn't count on
> it being enough to fool GHC -O2!  You probably want to use
> unsafeInterleaveIO like we do in GHC's UniqSupply library.
>
> Also, I'd replace the MVar with an IORef and use atomicModifyIORef for
> speed.
>
> Cheers,
>        Simon
>


More information about the Glasgow-haskell-users mailing list