[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: DRAFT Issue: UNREAD-CHAR-AFTER-PEEK-CHAR (Version 1)
- To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
- Subject: Re: DRAFT Issue: UNREAD-CHAR-AFTER-PEEK-CHAR (Version 1)
- From: cutting.pa@Xerox.COM
- Date: 10 Oct 88 11:03 PDT
- Cc: Masinter.PA@Xerox.COM, CL-Cleanup@SAIL.Stanford.EDU, Cutting.PA@Xerox.COM
- In-reply-to: Kent M Pitman's message of Mon, 1 Aug 88 14:32 EDT
"- 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
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.