Below is a reply I got from Steve Haflich on this subject.
I guess what it comes down to is that when I switch the stream element
type between character and byte I also must be toggling whether it's
interactive ! Needless to say, I'm not entirely satisfied.
I don't see that listen should have anything to do with interactivity
in the sense of whether it makes sense to ask a question. It ought
to just tell you whether there's something ready for you to read.
Date: Tue, 4 Apr 2000 14:43:31 -0700
From: don@... (Don Cohen)
Subject: question about common lisp standard
The listen function is described as telling you whether there's a
"character" available. Is this supposed to mean that on binary
streams it whould always return false? Or should it tell you whether
there's a byte available? Could this be a simple oversight? Or is it
a conscious choice (and if so, why)? Are you the right person to ask?
If not, who is?
I'm not the correct person to ask as I am no longer involved with
Franz' Common Lisp products. I'll give a quick (but unauthoritative)
explanantion of the ANS as one of its drafters.
listen &optional input-stream generalized-boolean
Returns true if there is a character immediately available from
input-stream; otherwise, returns false. On a non-interactive
input-stream, listen returns true except when at end of file1. If an
end of file is encountered, listen returns false. listen is intended
to be used when input-stream obtains characters from an interactive
device such as a keyboard.
In the portable language there is no way to create an interactive
stream. An implementation might idiomatically provide one for an
interactive connection to the user, and that stream is implied to be a
character stream. The only portable way a user can create a stream
(ignoring compound streams) is with OPEN, which is necessarily a
file-stream and non-interactive. (Ignore the irregularity that Unix
devices and named pipes have names in the file system and might
sometimes be more usefully connected to interactive streams.)
These portable capabilities of LISTEN (as well as stream creation and
stream capabilities) are so impoverished as to be nearly irrelevant to
real current programming needs, unless you can survive by writing dumb
tty-in tty-out applications. For real use, programmers need to depend
on the particular platform's (i.e. ACL) extensions, and keep in mind
the directions in which those are developing for the future. That
question is best directed to the regular bugs@... support