Issue PEEK-CHAR-READ-CHAR-ECHO

[Kim A. Barrett <IIM@ECLA.USC.EDU>]

Further discussion of this issue here at IIM has lead us to conclude that the
decision made at the Hawaii meeting to accept the proposal
PEEK-CHAR-READ-CHAR-ECHO:FIRST-READ-CHAR was a mistake.  Some of the arguments
against it involve flexibility of implementation, but none of us have time to
really do a proper job of writing up those arguments just now.  Besides which,
the argument some of us have found most compelling has nothing to do with
implementation flexibility.

The primary argument against the passed proposal is that an effort should be
made to make input appear "where it is used".  For example, consider a
read-eval-print loop which prompts with a "* ".  Now consider the following
sequence of input characters:

  'foo(+ 5 5)

Under the proposal as adopted, if the read-eval-print loop were operating on an
echo stream (which *standard-output* is bound to), then the resulting output
would be 

  * 'foo(
  FOO
  * + 5 5)
  10
  *

Note how the open-paren is misplaced.

Note that the input and output streams of the echo-stream could have been
string-input/output-streams, so this has nothing to do with possible line
oriented, pre-echoed input, as discussed in the proposal.  In fact, the whole
discussion of operating system considerations in the proposal is misleading,
since the proposal is describing the behavior of echo-streams, which may have
very little to do with the streams used for direct terminal io, screen
manipulation, and etc.

We wish to have this issue reconsidered.

kab
-------