[GHC] #3041: Arch independent binary representations

[GHC]

#3041: Arch independent binary representations
---------------------------------+------------------------------------------
    Reporter:  nomeata           |        Owner:         
        Type:  feature request   |       Status:  new    
    Priority:  normal            |    Milestone:         
   Component:  Compiler          |      Version:  6.10.1 
    Severity:  normal            |   Resolution:         
    Keywords:                    |   Difficulty:  Unknown
    Testcase:                    |           Os:  Linux  
Architecture:  Unknown/Multiple  |  
---------------------------------+------------------------------------------
Comment (by simonmar):

 Replying to [comment:7 igloo]:

 > Is there a reason for GHC not to use `Data.Binary` too? The only reason
 I can think of would be to avoid the extra dependency, but if haddock uses
 it then the GHC build depends on it anyway. Personally, I don't think it's
 a strong enough reason to maintain our own Binary anyway.

 I've been lead to believe that the performance of `Data.Binary` isn't as
 good as our `Binary` library.  I don't have figures to back that up, but
 performance of reading interface files is pretty important to us.  So I've
 been holding off on switching until `Data.Binary` has had some tuning.

 > So if GHC switches to `Data.Binary`, then all haddock needs to do is
 wait.

 Haddock just needs a binary serialisation library, there's no reason it
 has to use the same one as GHC.  And even if GHC switched, Haddock would
 have to be updated to use `Data.Binary` too.

 > In the mean time (i.e. for 6.10.2), we can fix the immediate problem by
 changing the `Int` instance to to serialise as `Int32` or `Int64`
 consistently.

 I think that's a bad idea.  If we use `Int64` then interface files get
 bigger on 32-bit machines; if we use `Int32` then we introduce new failure
 modes.  We could use some hybrid encoding I suppose, but I'd rather
 Haddock was just decoupled from GHC's binary library altogether.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3041#comment:9>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler