1. A file is not a stream. It really isn't anything like a stream. Sure, you can _make_ a stream based on a file but that's a different thing. A file is a list (ignoring for the moment meta-information), accessible at any point. By contrast, streams access either incoming or outgoing entities, optionally with "end of stream" support. For incoming, one may 'skip' but not 'seek'. For outgoing, one may send a series of predefined 'zero' values. Call that "seek" if you want, I don't.

I couldn't agree more. I came across exactly these issues while rewriting GHC's I/O library recently, so now GHC's Handle type internally has two constructors: - FileHandle (a handle to a file, seekable, with a single file pointer and a single buffer that contains either pending read or write data but not both). - DuplexHandle (a read/write stream, not seekable, with two completely independent buffers, and the two ends can be closed independently). strangely, a FileHandle is also used for a uni-directional stream, because it only needs a single buffer. For Concurrent Haskell there's a locking issue here: you can't expect two threads to read and write simultaneously to the same file, but it is entirely reasonable for two threads to be simultaneously reading and writing on the same socket. Hence a FileHandle has a single lock, and a DuplexHandle has one lock for each channel. In effect there's one lock per buffer.

2. A file is not made of "Char"s. A file is made of octets ("bytes"), i.e. Word8s. What is a "Char" anyway? Sometimes it's a seven- or eight-bit quantity with a _vague_ implication of interpretation as textual character; sometimes it's a 16-, 20.087- or 31-bit quantity with a much stronger implication of interpretation as textual character (strictly, Unicode "codepoint"). Is an ASCII 'r' the same as an EBCDIC 'r'? Or is an ASCII code 57 the same as an EBCDIC code 57?

As for streams, mostly they are streams of octets. But of course streams of anything might be useful.

There's an implicit conversion step, between whatever is the on-disk encoding of character streams and Unicode. GHC currently only supports a straightforward ISO 8851 encoding. I agree there ought to be a way to get at the raw bytes too.

3. Output streams ("sinks") are different from input streams ("sources"). That POSIX entity known as "standard output" is a sink of octets. A "bi-directional" stream such as a TCP connection is nothing but a source and a sink considered together. Indeed, for TCP it's possible to send "end of [outgoing] stream" without affecting the incoming stream. This is rather different from a contrived "file-access"-type stream, where reading and writing are operations affect each other.

Yup, see above.

There is no such thing as "I/O" unless, as in Haskell, one means _all_ imperative action. There are various entities out in the world accessible in a variety of different ways. Sources, sinks, lists, etc. are but some of the models useful for accessing them.

Ok, I agree so far. Are you suggesting the IO library should be changed? How? I considered providing a different API for bidirectional streams, or perhaps requiring that bidirectional streams use separate Handles for read and write, but came to the conclusion that the user really doesn't care whether under the hood a single Handle is using separate buffers for read and write or just a single buffer, how much locking is going on or whatever. The fact that these things are awkward to implement shouldn't show through in the library interface. It's definitely more convenient from the programmer's point of view to be able to use the *same* handle object for both read and write, otherwise you have to explain to people why they can have a read/write file handle but not a read/write handle for a TCP socket. Cheers, Simon