lazy ByteStrings: toChunks

[Duncan Coutts]

On Wed, 2007-01-24 at 07:32 +1100, Donald Bruce Stewart wrote:
> > 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.

In the worst case of representation change, toChunks could still return
a single massive chunk.

> 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. 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 idea originally was to avoid unnecessary strictness.

The other reason that we decided to include toChunks and decided not to
include a function that converts to a strict byte string is that I
didn't want to hide the expense of the operation from the user. toChunks
is O(1) and should remain O(1) with any reasonable representation change
that I can think of. toStrict however is O(n) and has to force the whole
stream into memory and copy it. It's expensive. If the user writes
(B.concat . toChunks) then this expense is explicit since they already
know that B.concat incurs that expense.

So I vote for the status-quo.

Duncan