ByteString I/O Performance

[Don Stewart]

bos:
> It is perfectly true that you can take an existing ByteString and smoosh 
> its innards however you like, because the authors sensibly made this 
> possible.  However, doing so breaks referential transparency, so it's 
> not encouraged as a general principle.  The fact that a ByteString has a 
> pointer to a nice flat piece of memory inside is an implementation 
> detail, and doesn't change the fact that it's intended to be immutable.
> 
> If you personally know for sure that you're not going to accidentally 
> screw yourself by running a lazy computation on a ByteString that you 
> then modify while the computation is still thunked, then by all means, 
> go to town.  But any claim that this is generally a safe thing to do 
> would be completely wrong.  It's very much in the realm of "here's the 
> gun, there's your foot, be careful".

Perhaps Peter just wishes to define a newtype MutableByteString type for
mutable use, with much the same representation as the existing immutable
ByteString, but without the purity guarantees and with all operations in IO?

-- Don