ByteString I/O Performance
dons at galois.com
Thu Sep 6 13:45:33 EDT 2007
> 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?
More information about the Libraries