Hi, Am Montag, den 06.10.2014, 19:55 +0000 schrieb p.k.f.holzenspies@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@joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nomeata@joachim-breitner.de • GPG-Key: 0xF0FBF51F Debian Developer: nomeata@debian.org