[Haskell] ANN: blaze-builder-0.2.0.0

[Simon Meier]

Hi Antoine,

Can the same technique be ported over to the binary package, or is it
> somehow interface incompatible?
>

I'm not exactly sure what you mean by the same technique.

If you mean using blaze-builder instead of Data.Binary.Builder as the Monoid
that the Put writer monad in the Binary typeclass is using, then, yes, you
can because Blaze.ByteString.Builder is a drop-in replacement for
Data.Binary.Builder. However, in that case you loose some of the speedup of
blaze-builder with respect to Data.Binary.Builder. The results

  https://gist.github.com/664979#file_comparison_to_binary_package.txt

of the throughput benchmark (ported from the binary package)


https://github.com/meiersi/blaze-builder/blob/master/benchmarks/BenchThroughput.hs

essentially show that you should not use the Put monad but the underlying
Monoid directly for serialization. In my opinion, it is also not necessary
to have a Writer monad (Put) by default. The only real benefit it brings is
the nice do-notation. However, for the syntax we would rather go for a
MonoidCatSyntax extension that introduces a 'cat' keyword analogously to the
'do' keyword. That's an extension which would also come in very handy for
blaze-html and possibly other mappend-heavy applications.

If you mean the Write abstraction, then its a partial yes. You can port it
to binary, but I'm not sure how big the win is going to be. The current
Data.Binary.Builder implementation suffers the problem that each builder
needs to know the strategy for output construction and hence, the whole
state of output construction. Passing all that data around makes its
`mappend` implementation quite slow.

I'd thought I'd heard rumbles a while back about a desire the change
> the implementation of 'binary', but I don't know what happened to
> that.


I also heard some rumbles, but nothing concrete. Perhaps one of the 'binary'
developers could comment on that issue?

best regards,
Simon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell/attachments/20101108/e1c85db2/attachment.html