Unique as special boxing type & hidden constructors

[p.k.f.holzenspies at utwente.nl]

On Wed, Aug 20, 2014 at 1:47 PM, <p.k.f.holzenspies at utwente.nl<mailto:p.k.f.holzenspies at utwente.nl>> wrote:


<thread_id_bits:8> <unique_id_bits:56-X> <tag_bits:X>


Is the thread id deterministic between runs?  If not, please do not use this layout.  I remember vaguely Unique being relevant to ghc not having deterministic builds, my most wanted ghc feature:

https://ghc.haskell.org/trac/ghc/ticket/4012


I think this depends on the policy GHC *will* have (there is not parallel build atm) wrt. the forking of threads. An actual Control.Concurrent.ThreadId might be as large as 64 bits, so, of course, we won't be using that, but rather the sequence number in which the UniqueSupply was "split off" for a new thread. In other words, if the decision to fork threads is deterministic, so are the Uniques with this layout.

Mind you, I imagine a parallel GHC would still have at most one thread working on a single module. I don't know too much about what makes it into the interface file of a module (I can't imagine the exact Uniques end up there, because they would overlap with other modules - with per-module compilation - and conflict that way).

Can you comment on how (the layout of) Uniques relate to #4012 in a little more detail? It seems that if the Uniques that somehow end up in the interface files could simply be stripped of the thread id, in which case, the problem reduces to the current one.

Ph.




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140820/09b26544/attachment.html>