stanonik@nprdc.arpa (Ron Stanonik) (01/11/89)
We've just started using Sun Common Lisp 2.1.1 (Lucid really?) on a Sun 3 running SunOS 3.5, so sorry if this has come up before. A program developed under this lisp, failed to work on a Symbolics 3670 running Genera 7.2. The problem seems to be that the program does something like (setq c (read-char)) (if (eql (peek-char) #\space) (unread-char c)) That is, if the peek-char is a space, the program unread's the previous char. Genera complains correctly (as I read CLtL, 1984) about trying to unread two characters in a row; ie, the peek-char is equivalent to read-char followed by an unread-char. Sun Common Lisp unread's two (maybe more?) characters without complaint, which allowed the program to work even though it violated the Common Lisp spec. KCL also allows two (maybe more?) unread's in a row. Ron Stanonik stanonik@nprdc.arpa ucsd!nprdc!stanonik
barmar@think.COM (Barry Margolin) (01/11/89)
Common Lisp does not require an implementation to complain if you try
to do more than one unread in a row (CLtL doesn't say that doing so
"signals an error"). It merely specifies that no implementation is
required to allow more than one. In other words, every implementation
must allow at last one unread-char in a row. So, all the
implementations you described conform to the spec.
In some implementations, the actual number of characters that may be
unread may depend on the stream. For instance, a file stream may
allow unreading all the way back to the beginning of the file, because
it simply reposition's the file offset, but a terminal stream might
require the Lisp implementation to do its own buffering and it could
chose to maintain only a single character buffer.
Barry Margolin
Thinking Machines Corp.
barmar@think.com
{uunet,harvard}!think!barmarstanonik@nprdc.arpa (Ron Stanonik) (01/12/89)
Hmm, my version of CLtL (1984) says: "Moreover, one may not invoke unread-char twice consecutively without an intervening read-char". Has that changed? Thanks, Ron Stanonik stanonik@nprdc.arpa ucsd!nprdc!stanonik