lazy ByteStrings: toChunks

[Ross Paterson]

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.