Dear all,
I *finally* had some time again to look at how to properly redo Uniques in GHC. A few things stood out to me: - The export-list of Unique has some comments stating that function X is only exported for module Y, yet is used elsewhere. This may be because these comments do not show up in haddock etc. leading some people to think they're up for general use. In my refactoring, I'm sticking the restriction in the function name, so it's no longer mkUniqueGrimily, but rather mkUniqueOnlyForUniqSupply (making the name even longer should discourage their use more). If at all possible, these should be removed altogether asap. - The implementation is based on FastInts, which, on most machines nowadays, is a 64-bit thing. The serialisation in BinIface is explicitly based on Word32s. Aside from the obvious potential (albeit with a low probability) for errors, this lead me to wonder about 32/64-bitness. Is there a reason for 64-bit versions of GHC to write Word32s, or is this a historic thing? Must the interface-files be bit-compatible between different versions (32/64-bits) of the compiler? Lastly, is the choice of whether "this" is a 32 or 64-bit version completely determined by WORD_SIZE_IN_BITS (MachDeps.h)? - There are a few libraries that are explicitly dependent on GHC, yet have their own versions of Unique. So far, I've seen this for Hoopl and Template Haskell. They have unboxed ints to do the job. I have not researched whether they manipulate them in any way, or just store things. If the former; I would like to call to reconsider this, because it seems like a poor separation of concerns toe me. If the latter, I think refactoring them to use Unique instead of Int# should be straightforward. ? The point of refactoring Unique is to no longer have low-level optimisations of manually unpacking (and repacking using the MkUnique constructor), which should serve as a lovely test of how far the optimisations have come. Furthermore, it seemed that the use of characters to encode the domain was somewhat awkward, but I refer anyone interested to earlier posts on this list. Thoughts? Comments? Suggestions? Objections? Regards, Philip
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
