Daniel Hartwig: > Indeed. There is a distinction between the end-of-file _object_ > (Scheme) and end-of-transmission _character_ (ASCII ^D). The two are > not equivalent, ...
Sure. > 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. If I understand you correctly, that sounds more like "char-ready?". In any case, I believe guile fails to meet the semantics of R5RS, and I believe other versions of the Scheme spec, in this area. R5RS says: > (peek-char) procedure > (peek-char port) procedure > Returns the next character available from the input port, > without updating the port to point to the following character. > If no more characters are available, an end of le > object is returned. Port may be omitted, in which case it > defaults to the value returned by current-input-port. > Note: The value returned by a call to peek-char is the same as > the value that would have been returned by a call to read-char > with the same port. The only diff erence is that the very next call > to read-char or peek-char on that port will return the value > returned by the preceding call to peek-char. In particular, a > call to peek-char on an interactive port will hang waiting for > input whenever a call to read-char would have hung. Note that the spec says that the very next call "to read-char or peek-char on that port will return the value returned by the preceding call to peek-char." It does not say the same *CHARACTER*, it says the same *VALUE*, and the eof object is a possible value from peek-char and read-char. I'd be okay if, after a read-char of EOF, it could return something else as some sort of extension. But (peek-char) (peek-char) (peek-char) should return the same values 3 times, no matter what... even if it's EOF. --- David A. Wheeler
