Again: Uniques in GHC

[Joachim Breitner]

Hi,

Am Montag, den 06.10.2014, 19:55 +0000 schrieb p.k.f.holzenspies at utwente.nl:
> Although I can't quite get what you're saying from the posts on that
> link, I'm not immediately sure what you're saying should extend to
> hi-files. These files are very much specific to the compiler version
> you're using, as in, new GHCs add stuff to them all the time and their
> binary format does not (seem to) provision for being able to skip
> unknown things (i.e. it doesn't say how large the next semantic block
> is in the hi-file).

Some of this may not be true, but to my knowledge (part of) that
interface reading code is (or was?) used by haddock when generating
its .haddock file.

> If we're going to keep the formats the same for any architecture,
> we're going to have to limit 64-bit machines to 32-bit (actually
> 30-bits, another thing I don't quite understand in BinIface) Uniques.

Why? You can just serialize Uniques always as 64 bit numbers, even on
32-bit systems. This way, the data format is the same across
architectures, with little cost.

>  There seem to be possibilities to alleviate the issues with parallel
> generation of fresh Uniques in a parallel version of GHC. The idea is
> that, since 64-bits is more than we'll ever assign anyway, to use a
> few for thread-ids, so we would guarantee non-conflicting Uniques
> generated by different threads.
> 
But that would only work on 64 bit systems, right?

Greetings,
Joachim

-- 
Joachim “nomeata” Breitner
  mail at joachim-breitner.de • http://www.joachim-breitner.de/
  Jabber: nomeata at joachim-breitner.de  • GPG-Key: 0xF0FBF51F
  Debian Developer: nomeata at debian.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20141006/fdfc0343/attachment.sig>