On Wed, Jan 19, 2011 at 6:51 PM, John Millikin <[email protected]> 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 _______________________________________________ Haskell-Cafe mailing list [email protected] http://www.haskell.org/mailman/listinfo/haskell-cafe
