[R6RS] I/O

[Matthew Flatt]

At Tue, 11 Jul 2006 15:09:38 -0400, William D Clinger wrote:
> > There are certainly other ways to encode it, but they all come down to
> > returning a special value.  Moreover, some platforms (like Unix,
> > AFAICS) don't allow you to distinguish between a "terminal" end of
> > file and a "temporary" one.  What would you have, say, `peek-byte'
> > return when no data is available, but terminal end of file has not
> > been reached?
> 
> I would guess that you are assuming a model in which some
> character, e.g. END OF TRANSMISSION, popularly known as
> control-D, is interpreted as an end of file when typed.
> 
> I would prefer a model of interactive ports that does not
> impose any such interpretation upon legitimate Unicode
> characters, and delivers an end of file object only when
> the interactive port is closed, e.g. by a procedure such
> as close-input-port.

When you type control-D in a Unix terminal, it doesn't actually insert
a control-D into the input stream connected to the terminal. Instead,
the terminal handles the control-D in such a way that the stream
returns an end-of-file to the reader (i.e., the read() system call
returns 0, which indicates an end-of-file).

In other words, at the Unix stream level, it's not a question of
keyboard handling or interpreting characters. The underlying Unix
stream model supports EOF results that are followed by non-EOF results.

Whether we want to support this facet of Unix streams is a valid
question. I think Mike's correct when he says that there's no way to
distinguish a mid-stream EOF from a terminating EOF (even though there
must be some difference in the implementation of Unix pipes). One way
to avoid mid-stream EOFs is to treat any EOF from a Unix stream as a
terminating EOF. That is, after receiving an EOF from a Unix-level
stream, the port thereafter ignores the stream and always returns EOF.
I'd prefer to have mid-stream EOFs, though.

Matthew