Skip to content

Update Binary serialization and extensible interface files

Motivation

The current Binary implementation unnecessarily exposes an exclusively IO interface, preventing a pure encode/decode. Without a pure decode, deserialization of optional fields in an extensible interface file is messy.

By hiding the data currently contained in the BinHandle type behind reader newtypes, the Binary class can present a pure interface to serialize/deserialize data, without leaking the mutable buffer.

Additionally, these readers should make it easier to generalise the inclusion of symbol tables and dictionaries that BinIface.putWithUserData and HieBin.writeHieFile use to serialize Name and FastString.

Proposal

Binary Improvements

  • Update Binary to use Put/Get newtypes containing ReaderT IO, allowing encode/decode to be written (!1960)
  • Logic is almost entirely duplicated between ghc.BinIface.{readBinIface, writeBinIface}, ghc.HieBin.{readHieFile, writeHieFile}, and haddock.Haddock.InterfaceFile.{readInterfaceFile, writeInterfaceFile}
  • With the buffer handle and IO hidden behind the readers, it will be significantly easier to switch out the implementation for one of the standard implementations. This was previously discussed in #3379 with binary, and cereal is another option. Name and FastString complicate the symmetry of encode/decode for lawful instances in these standard implementations, so the GHC Binary class can remain separate while borrowing the internals of the chosen implementation.
Edited by Simon Jakobi
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information