Issue: UNREAD-CHAR-AFTER-PEEK-CHAR (Version 1)

[masinter.pa@Xerox.COM]

Issue:         UNREAD-CHAR-AFTER-PEEK-CHAR

References:    pp 379, 380 of CLtL

Category:      CLARIFICATION

Edit history:  Version 1 by Doug Cutting <Cutting.PA@Xerox.COM> on July 29, 1988

Problem description:

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.

Proposal (UNREAD-CHAR-AFTER-PEEK-CHAR:DONT-ALLOW): UNREAD-CHAR may not be called
after PEEK-CHAR without an intervening call to READ-CHAR.

Test Cases/Examples:

;;; Following is an example of code which should not be valid CL.
(defun test (stream)
 (let ((char (read-char stream)))
  (peek-char nil stream)
  (unread-char char stream)
  (assert (eql char (read-char stream)))))

Rationale:

PEEK-CHAR and UNREAD-CHAR provide equivalent functionality and it is thus
reasonable for an implementation to implement them in terms of the same
mechanism.

Current practice:

In Xerox Common Lisp, different (non-random-access) stream types behave
differently. One, (TCP/FTP) handled this correctly, while another (keyboard with
line-buffering turned off) did not.

Cost to Implementors:

Zero.  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.

Benefits:

Allows simple yet adequately powerful implementation of sequential streams.

Esthetics:

Requires that users have shared, one-char buffer model of how UNREAD-CHAR and
PEEK-CHAR work, rather than two separate one-char buffers.

Discussion: