ByteString I/O Performance

[Bryan O'Sullivan]

Peter Simons wrote:

> Bryan, my mood would be a lot better if you would address my
> technical points on this list instead of my mood. 

I find that people are more responsive when not being flamed, and when 
they get the sense that their helpful words aren't falling on deaf ears.

> I realize this discussion is going nowhere. It's hard for me to
> understand how people manage to say things like "you can't do
> that" despite the fact that I posted code which does exactly
> that, but I guess I don't have to understand everything.

I think the manner in which people are talking past each other revolves 
around what's *possible* versus what's *sensible*.

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".

	<b