listen, etc.

[edsel!jim@su-navajo.arpa (Jim McDonald)]

CLtL currently says "The predicate LISTEN is true if there is a
character immediately available from input-stream, and false if not."

This precludes any reasonable use for LISTEN on non-character streams,
which seems to me to be a flaw.  It is not hard to imagine a program that
loads binary data from a network while carrying on other tasks (like 
responding to the user!) during the pauses between arrival of packets.
There might even be non-character, non-byte streams that act as pipes
or queues of complex objects.  It would be useful if LISTEN could be
used to poll arbitrary input streams, even if many such applications
might be handled better by interrupt-driven routines.

Are there any objections to changing the definition to say "The predicate
LISTEN is true if a transaction datum is immediately available from
input-stream, and false if not."?

Note that with this revised definition, READ-CHAR-NO-HANG and potential,
analogous, routines such as READ-BYTE-NO-HANG would be too specialized
to define LISTEN.  Thus as long as the change I propose is not completely
ruled out, it would be premature to define LISTEN in terms of 
READ-CHAR-NO-HANG.

---

In a similar vein, the book groups CLEAR-INPUT among those routines that
act on character streams, but the definition itself does not seem to imply
that the stream must be a character stream.  Likewise, FINISH-OUTPUT, 
FORCE-OUTPUT, and CLEAR-OUTPUT are grouped with functions on character
streams, but seem to be reasonable for arbitrary output streams.
I propose that such routines should work for all streams with the 
appropriate direction.  Could someone involved with their definition
clarify this?

---

Would READ-DATUM, PEEK-DATUM, READ-DATUM-NO-HANG, and UNWRITE-DATUM be
appropriate stream functions, with -CHAR- and -BYTE- forms available for
clarity and/or efficiency?  

---

Finally, have there been any proposals for mechanisms to create
non-character, non-byte streams, and if not, is it due to lack of 
interest or lack of agreement?  I think a good queueing primitive
would find many uses.

  Jim McDonald