Hi Bas, I'm not sure the unpacking is absolutely necessary. It might be worth to give it a try with not-unpacked strict chunks. In some of my ByteString builder experiments, I even got better performance by not unpacking the ByteStrings in some of the intermediate data structures. My gut feeling says that compensating the extra indirection is not too hard provided you ensure that your chunks are large enough. The corner case of having lots of small lazy bytestrings is likely to be slower. Experiments will tell. best regards, Simon 2012/7/12 Bas van Dijk :

On 12 July 2012 15:35, Yves Parès wrote:

...

I remember this discussion, lazy vectors would also enable an implementation of bytestring and (maybe) text only with unboxed vectors, unifying it all: type ByteString = Vector Word8

Yes, I would like to add a lazy storable vector to vector-bytestring[1] to make the API 100% consistent with bytestring.

Ideally we would have a type like:

data Lazy vector a = Empty | Chuck {-# UNPACK #-} !(vector a) (Lazy vector a)

Unfortunately GHC can't unpack polymorphic fields. The next best thing is to use a type family which for each type of vector would return its lazy version (where the vector is unpacked in the cons cell). Then we would need a class for common operations on those lazy vectors.

Regards,

Bas

[1] http://hackage.haskell.org/package/vector-bytestring https://github.com/basvandijk/vector-bytestring

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe