bug#12216: peek-char incorrectly *CONSUMES* eof

[Daniel Hartwig]

On 8 March 2013 05:32, Andy Wingo <address@hidden> wrote:
> On Tue 05 Mar 2013 20:17, "David A. Wheeler" <address@hidden> 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.