[Haskell-cafe] Adding a builder to the "bytestring" package?

[John Millikin]

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?