I/O generic functions

[Mike McMahon <MMcM@STONY-BROOK.SCRC.Symbolics.COM>]

This is the right sort of start.  I have a few observations which are
not meant to be comprehensive.  They might help stimulate further
careful design.

STREAM-LISTEN is actually not mandatory: you can implement it using
READ-CHAR-NO-HANG and UNREAD-CHAR.

If people are going to start defining well behaved streams, some
protocols need to be firmed up.  For instance, if LISTEN is true, must
READ-CHAR-NO-HANG return a character?  Or is it only that
READ-CHAR-NO-HANG returns a character or clears the LISTEN condition?
You can see the difference in the behavior of an encapsulated stream
with escape characters.  In the one case, LISTEN can just do LISTEN on
the inside stream, which is presumably fast (e.g. checks some network
buffer pointers).  If the buffer contains only the start of an escape
sequence, READ-CHAR-NO-HANG will still not return a character.  In the
other case, LISTEN must run the entire decoding machinery right away and
unread any character it produces.  The key decision is whether you want
LISTEN to be complete or efficient.

Wouldn't it be better to have just one centralized implementation of
eof-error-p eof-value handling?  The internal stream methods could obey
just one protocol for returning EOF which the outer would process
independently.