[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

LISTEN Proposal



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 
the language?