
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