unique identifiers as a separate library

[Simon Marlow]

Isaac Dupree wrote:
> Sebastian Fischer wrote:
>> On Dec 17, 2008, at 10:54 AM, Sebastian Fischer wrote:
>>
>>> Would it be possible to put everything concerned with unique 
>>> identifiers in GHC into a separate package on Hackage?
>>
>>
>> I have wrapped up (a tiny subset of) GHC's uniques into the package 
>> `uniqueid` and put it on Hackage:
> 
> thanks!
> 
>> The main difference is due to my fear of depending on the foreign 
>> function `genSymZh` which I replaced by a global counting IORef.
> 
> which is its own risk.  maybe you should NOINLINE it?
> 
> Potential code criticisms / suggestions for it as a library:
> 
> Unboxed: so it only works on GHC, even though others have unsafe IO 
> too.  In theory, strictness annotations should be able to achieve the 
> same efficiency.
> 
> "Char" is supposed to represent a Unicode character -- but this code 
> behaves oddly:
> For 64-bit Int#, it does so.
> For 32-bit Int#, it assumes Char is within the first 8 bits (ASCII and a 
> little more).
> If Int# (or Int) can be 30-bit (like Haskell98 permission), its 
> correctness suffers even worse.
> Is it really even a necessary part of the design?  The only way you 
> provide to extract it or depend on its value is indirectly via the 
> "Show" instance.  Its presence there is, in any case, at the cost of 
> max. 2^24 (16 million) IDs before problems happen, whereas billions is 
> still not a great limit but at least is somewhat larger. (applications 
> that are long-running or deal with huge amounts of data could be affected)
> 
> unsafeDupableInterleaveIO: this "Dupable" was safe for GHC to use 
> because GHC is single-threaded.  Is it safe in a library setting?

It would be safe if the genSym was atomic - so I recommend using 
atomicModifyIORef.

Cheers,
	Simon