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

[cutting.pa@Xerox.COM]

"- A misreading of the proposal might lead one to believe that one could
   do (SETQ CH1 (READ-CHAR STREAM))
      (SETQ CH2 (PEEK-CHAR NIL STREAM))
      (SETQ CH3 (READ-CHAR STREAM))
      (UNREAD-CHAR CH1 STREAM)
   since the unread-char is correctly separated from the PEEK-CHAR by an
   intervening READ-CHAR. The problem is that the wrong char is being
   unread. Some implementations support this, but it's definitely not
   condoned by the description of UNREAD-CHAR on p379."

I assume that the proposal, as a clarification, is to be read in the
context of CLtL.  Your example is already prohibited by CLtL, hence this
proposal need not address it.

There are thus a set of constraints on UNREAD-CHAR:

(1) UNREAD-CHAR must only be applied to the
    result of the last call to READ-CHAR;
(2) UNREAD-CHAR must not be called twice in succession
    without an intervening call to READ-CHAR;
(3) UNREAD-CHAR must not be called after PEEK-CHAR
    without an intervening call to READ-CHAR.

(1) and (2) are in CLtL and (3) is my proposed clarification.
Your example is prohibited by (1).

  "It would be clearer for the proposal to just say 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 portable."

I don't find this clearer, but I could live with it.

	Doug