In the last post I mentioned a few changes I'd like to see in the binary package. A commenter pointed out that the cereal package might provide a better starting point for implementing the API I want, due to its continuation based implementation.
The commenter might well be right. I don't really know whether the current cereal code base or Lennart's binary branch would serve as a better starting point. My understanding is that both implementations are very similar (i.e. continuation based.) I'd go with the faster one, whichever it is.
I think binary and cereal could benefit from a merger. Both libraries are very similar; they have 23 functions in common. The main differences are:
runGettakes a lazy
ByteString, in cereal it takes a strict one. The cereal version also allows for parse error handling by returning the result wrapped in
Either. Both the lazy and strict versions of
runGetare easily implemented  in terms of
runGetPartial, as presented in the last post.
isolate, a function that lets you run a parser on a part of the input, in isolation. It would be a nice addition to the binary interface. In fact, Duncan, Lennart, and I discussed adding such a feature to binary during ZuriHac.
cereal provides 11 functions for working with containers. These are nice to have, but I'd prefer if they were split of into a separate package in order to remove the dependency on containers. Parsing different sized machine words in different byte orders is much more fundamental than parsing e.g. a serialized
Map; we might want to use a different map type in a year but machine words will most likely still be 32 or 64 bits).
Below is a complete list of the differences.
Functions that exist in binary but not in cereal:
Functions that exist in cereal but not in binary:
- 11 container related functions.
If the libraries would merge we could:
Parse both strict and lazy
ByteStrings with the same parser.
Reduce implementation effort and user confusion.
According to this list of reverse dependencies, binary has many more direct dependencies, which suggests that cereal should be absorbed into binary and not the other way around to reduce breakages.
- Not quite true. You can't have both parse error handling, lazy parsing, and keep the binary's current type for
runGet. To know if you have a parse error implies forcing enough of the input to check. Right now binary doesn't really have a story for error checking.