alternate track on the char-ready? issue

[Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>]

    Date: Wed, 15 Jun 88 10:10:14 edt
    From: cph@kleph.AI.MIT.EDU (Chris Hanson)

       Date: Tue, 14 Jun 88 22:21:30 EST
       From: R. Kent Dybvig <dyb@iuvax.cs.indiana.edu>

       I proposed this a while back, but my proposal met with little or no
       response.  I propose that the name of the optional procedure
       "char-ready?" be changed to "read-char-ready?", to allow for
       generalization to "read-ready?", "write-char-ready?", and maybe even
       "write-ready?".

    I don't know about the other three, but I agree with your proposal to
    rename `char-ready?'.  I should have seconded this proposal the last
    time -- we blew it when we originally named that procedure.

I strongly believe that CHAR-READY? should not be part of any Scheme standard.

It is an embarrassing timing error waiting to happen that does not do justice
to the very careful design of most other parts of this language.

It presupposes a particular model of stream use that is not always appropriate
in a shared memory multi-tasking environment. For example, on the Lisp Machine,
if you type Function Clear-Input (asynchronous clear input buffer) between the
time you do the CHAR-READY? is done and the time you try to read a character,
the attempt to read the character will hang.

I strongly think we should flush CHAR-READY? and replace it with the following
primitive:

  (READ-CHAR?)
  (READ-CHAR? port)

  If a character is immediately available from the input PORT,
  that character is returned and the PORT is updated to point
  to the following character (if any). If characters are expected
  to become available but none are immediately available at the
  time of the call, #f is returned. If no more characters
  are available, an end of file object is returned. PORT may be
  omitted, in which case it defaults to the value returned by
  CURRENT-INPUT-PORT.

Some other possible names are READ-CHAR-NOW, READ-CHAR-IMMEDIATELY,
MAYBE-READ-CHAR, and READ-CHAR-IF-ANY. I'm not adamant about the details
of the proposal other than that a LISTEN primitive is just plain
wrong and a TYI-NO-HANG is much more defensible...