Conusion with peek-char and char-ready

[Jonathan S. Shapiro <shap@polya.Stanford.EDU>]

The conflict with char-ready? vs rubout handlers arises with peek-char
also, and it is very bad that the current draft requires no guarantee
that what I get from PEEK-CHAR is what I will get from a subsequent
READ-CHAR [I suspect this is a temporary editing discontinuity
introduced by the removal of CHAR-READY?].  This is emphatically *not*
the right thing, as it leads to an ambiguity in usage: one usage is to
use PEEK-CHAR to watch the instantaneous input stream, the other is to
do lookahead.  If the relationship between PEEK-CHAR and READ-CHAR is
not strengthened, this confusion will get embedded in programs in
subtle ways.

The problem arises out of a confusion between readahead and
rubout/kill processing. In the presence of rubout handling,
CHAR-READY? should only return #t if there is input that has been
committed (on a UNIX system, if return has been pressed for the input
line).  In the absence of rubout handling, (i.e. raw mode I/O),
CHAR-READY should return #t if a character has been typed.

This is getting pretty deep into terminal I/O specific stuff, and it
isn't clear to me that we ought to do that.

The problem can be temporarily resolved by restoring CHAR-READY? with
the interpretation above and introducing something like

	(I/O-MODE <port> 'BUFFERED)
	(I/O-MODE <port> 'RAW)

I think it would be better to do this than standardize on an I/O
facility in which there is no way to guarantee non-blocking read.

I am in general greatly concerned that the IEEE standardization is
very premature, and will lead to diverging practices in commercial
implementations that will make the language nearly impossible to
converge later.

Jon