Most people who work with binary data have had to construct bytestrings at some point. The most common solution is to use a "Builder", a monoid representing how to construct a bytestring. There are currently three packages (that I know of) which include builder implementations: binary, cereal, and blaze-builder. However, all of these libraries have additional dependencies beyond just "bytestring". All three depend on "array" and "containers", and blaze-builder additionally depends on "text" (and thus "deepseq"). Since the current implementation of GHC uses static linking, every additional dependency adds to the final size of a binary. Obviously the "Builder" concept is very useful, as it has been implemented at least three times. How about adding it to the "bytestring" package itself? We could have a module Data.ByteString.Builder, with functions (at minimum): toByteString :: Builder -> Data.ByteString.ByteString toLazyByteString :: Builder -> Data.ByteString.Lazy.ByteString fromByteString :: Data.ByteString.ByteString -> Builder fromLazyByteString :: Data.ByteString.Lazy.ByteString -> Builder empty :: Builder append :: Builder -> Builder -> Builder Plus whatever implementation details might be useful to expose. Existing libraries could then add their extra features (word -> builder for binary and cereal, UTF/HTTP for blaze-builder) on top of the existing types. Is this something the community is interested in? Is there any work currently aimed at this goal?