[R6RS] I/O

[Matthew Flatt]

At Thu, 13 Jul 2006 12:02:10 -0400, William D Clinger wrote:
> Mike wrote:
> > > If it's true, then stating that it is true would help.
> > > If it's false, then stating that it is false would help,
> > > but you would still have to explain what kind of objects
> > > are acceptable as a descriptor.
> > 
> > I tried to do that in the latest draft.  Better?
> 
> Yes, thank you.
> 
> > >> > 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.
> > >>
> > >> No.  I'm assuming a model where the other end sends a block of data
> > >> and then pauses temporarily (i.e. stops typing).
> > >
> > > Wow.  Please confirm:
> > 
> > No, you're right....
> > Your original statement quoted above is correct.  Sorry about that.
> 
> In that case, I beg you to change the specification of
> read-string-all so it returns #f when no data is available,
> instead of returning the end-of-file object.  As things
> stand, there is no way to distinguish between:
> 
>     1.  no character available at the moment; try again later
> and
>     2.  true end of file, forever and ever, amen.

As I understand it, there is no way to detect #1 at all. The SRFI
doesn't have any non-blocking operations.

In other words, an EOF wasn't intended as a "no data available right
now" result. It's intended as "no other data available before an EOF
that is available".


At Thu, 13 Jul 2006 12:02:10 -0400, William D Clinger wrote:
> Matthew wrote:
> > 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.
> 
> Ah, Eunichs.  Deficient by Design (service mark).

Show me something that works better (i.e., something that people
actually use).


Matthew