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
_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
