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 <v.dijk....@gmail.com>: > On 12 July 2012 15:35, Yves Parès <yves.pa...@gmail.com> 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 _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe