References: pp 379, 380 of CLtL
Edit history: Version 1 by Doug Cutting <Cutting.PA@Xerox.COM> on July 29, 1988
Version 2 by Masinter 2-Dec-88
PEEK-CHAR and UNREAD-CHAR are very similar mechanisms. The description of
PEEK-CHAR in CLtL even states that "it is as if one had called READ-CHAR and
then UNREAD-CHAR in succession." But while CLtL prohibits calling UNREAD-CHAR
twice in succession it does not prohibit calling UNREAD-CHAR after PEEK-CHAR.
The obvious implementation of PEEK-CHAR and UNREAD-CHAR (a one-character buffer)
will not work unless this prohibition is present.
Rewrite the specification so that it is clear that doing either a
PEEK-CHAR or READ-CHAR `commits' all previous characters. UNREAD-CHAR
on any character preceding that which is seen by the PEEK-CHAR (including
those passed over by PEEK-CHAR when `seeking' with a non-NIL first
argument) is not specified.
In particular, the results of calling UNREAD-CHAR after PEEK-CHAR
(defun test (&optional (stream *standard-input*))
(let* ((char1a (read-char stream))
(char2a (peek-char nil stream))
(char1b (progn (unread-char char1a stream)
(char2b (read-char stream)))
(list char1a char2a char1b char2b)))
This is not legal, since the PEEK-CHAR for char2a "commits"
the character read by char1a, and so the unread-char is not legal.
PEEK-CHAR and UNREAD-CHAR provide equivalent functionality and it is thus
reasonable for an implementation to implement them in terms of the same
In Xerox Common Lisp, different (non-random-access) stream types behave
differently. One, (TCP/FTP) handled this correctly, while another did not.
In Symbolics Genera, for the Example above:
=> (#\a #\b #\a #\b)
(with-input-from-string (s "abc") (test s))
=> (#\a #\b #\a #\b)
(progn (with-open-file (s "foo.output" :direction :output)
(write-string "abc" s))
(with-open-file (s "foo.output" :direction :input)
Signals an error about unreading #\a when #\b was already unread.
Cost to Implementors:
Presumably none. Implementations which allow this are still correct.
Cost to Users:
Small. I suspect there is very little code which depends upon this working
correctly, as most code uses either PEEK-CHAR or UNREAD-CHAR, but not both.
Cost of non-adoption:
Implementations of sequential streams are forced to be unnecessarily complex in
order to be correct.
Allows simple yet adequately powerful implementation of sequential streams.
Requires that users have shared, one-char buffer model of how UNREAD-CHAR and
PEEK-CHAR work, rather than two separate one-char buffers.