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/BenchThrough... 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