On Tue, Jan 23, 2007 at 09:02:31PM +0000, Duncan Coutts wrote:
On Wed, 2007-01-24 at 07:32 +1100, Donald Bruce Stewart wrote:
ross:
toChunks exposes the implementation, and so shouldn't be in the public interface, should it? There could be a function from lazy to ordinary ByteStrings (B.concat . toChunks), though.
No, I don't think it exposes the implementation that much. In particular we could change the internal representation from a list of chunks to a tree of chunks or a element-strict list of chunks without breaking the toChunks function.
OK, but it does break the abstraction (list of bytes), while B.concat . toChunks doesn't. I think that qualifies it as an internal interface.
That seems reasonable. All uses I've ever had for toChunks involve also concat'ing them.
This is indeed the most common use however libraries like zlib/bzlib compression, charset conversion, encryption, (de)serialisation etc that need to work on contiguous chunks of memory need to be able to get at the chunks.
Can you point at some examples? I had a quick look, but couldn't find any uses of toChunks not preceded by concat. I would expect most of those examples to operate on substrings that might span chunk boundaries.
The only other thing they can do is to import the internal module and get at the LPS constructor which is more evil and will break if we change the underlying representation (and I do intend to experiment with making the lazy byte string rep use element-strict lists to remove one indirection).
The internal module could offer different levels of interface, though.