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

Johan Tibell johan.tibell at gmail.com
Wed Jan 19 20:32:53 CET 2011


On Wed, Jan 19, 2011 at 6:51 PM, John Millikin <jmillikin at gmail.com> wrote:
> 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?

I think both Duncan and I agree that we should move
Data.Binary.Builder (which doesn't have any extra dependencies) to
bytestring. I've already added Data.Text.Lazy.Builder to text.

Johan



More information about the Haskell-Cafe mailing list