[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
- To: common-lisp@su-ai
- Subject: LISTEN Proposal
- From: robbins@DEC-HUDSON
- Date: Sat, 21 Sep 85 10:31:45 EDT
- Cc: GSB@MIT-MC
Obviously there is no pressing need to do anything to the current
definition of LISTEN. However, I think that it is kind of strange to
have a pair of similar functions whose definitions are just inconsistent
enough so that the "intuitive" implementation of one fails.
... one can always do
(defun listen (&optional (input-stream *standard-input*))
(let ((char (read-char-no-hang stream nil nil)))
(cond ((null char) nil)
(t (unread-char char) t))))
I agree that this will work just fine. Am I the only one who objects to
the extra IO implicit in this definition?
From the definition of READ-CHAR-NO-HANG CLtL page 380:
"LISTEN does not distinguish between end-of-file and no
input being available, whereas READ-CHAR-NO-HANG does
make that distinction returning EOF-VALUE at end-of-file ..."
Is there a good reason for this seemingly gratuitous inconsistency in