On 8 March 2013 05:32, Andy Wingo <wi...@pobox.com> wrote: > On Tue 05 Mar 2013 20:17, "David A. Wheeler" <dwhee...@dwheeler.com> writes: > >> I reported: >>> > Guile's peek-char has a bug; it incorrectly *consumes* eof instead of >>> > just reporting it. >> >> Andy Wingo replied: >>> I have the feeling that for interactive use, if you expect to read a EOF >>> from a port and then continue, you have to not use peek-char. You need >>> to handle your own lookahead buffer. I know it's not a great answer, >>> but I can't think of anything else that makes sense. >> >> We don't want to read an EOF and then continue. >> We peek-char to not *CONSUME* an interactive EOF. > > I understand what it is you want. But I don't know of any sane way to > implement it.
Indeed. There is a distinction between the end-of-file _object_ (Scheme) and end-of-transmission _character_ (ASCII ^D). The two are not equivalent, and when read-char and peek-char return the former value it is only to signal a _current_ lack of characters and should not be considered part of the character stream read from the port. This is the same reason why, e.g. the end-of-file object can not be passed to unread-char: it is not a character. IIRC some other Schemes do handle the test case from OP, but I do not agree that those semantics are sane.
