Subject: [clisp-list] clear-input not working from dos box?

From: [email-masked] (Don Cohen)
Date: Fri Nov 8 21:31:01 2002

I'm running clisp 2.30 on a windows machine from a shortcut that
starts it in a command prompt.  When I ran from emacs I think this
worked, but from the command prompt it doesn't.
I can do something like
 (list (read)(read)(clear-input)(read))
then type (on one line)
 2 3 4 5
and I get back (2 3 nil 4)
I trace read and clear-input and see output like this:

...
trace: (clear-input) ==> nil
trace: (read)
trace: (read) ==> 4
...

I also tried programming my own clear-input using listen but listen
seems to return nil even when I think it should return t.

Does this happen to anyone else out there?

---

From: Kaz Kylheku <[email-masked]>
Date: Sat Nov 9 09:14:02 2002

On Fri, 8 Nov 2002, Don Cohen wrote:

> Subject: [clisp-list] clear-input not working from dos box?
> 

This is probably because CLISP is reading your terminal input in
character-at-a-time mode. So the read of 3 completes as soon as the
space character is read in, and no additional characters are buffered
from the operating system. No characters buffered means that there is
nothing to discard. This is how CLISP behaves on Unix.

Anyway, clear-input and its ilk are braindamaged. You are telling the
machine to throw away data.  There is no protocol for doing this right,
so the software is likely to irritate the user who types ahead the
computer's response, due to network lag or delays in the program
itself that create uncertainties in what exactly is discarded.

If I'm typing ahead, and the machine tries to discard input, it's possible
that some of the typed-ahead characters remain, because they were still
arriving to the machine *after* the clear operation executed. It's a
race; there is no end to end synchronization to bring about any
agreement about how much is discarded.  So to get reliable behavior,
I'm going to have to train myself to wait for the appearance of the
input prompt before typing anything, because that prompt is the only
thing that tells me that the software has already tried to throw away
my input, and is truly ready now to receive it! Because I'm a fast
typist who can type entire lines of correct input to a lagged system,
this will irritate me to the point that I will throw the program away.

Note the large comment in the CLHS example for clear-input:

;; The exact I/O behavior of this example might vary from implementation
;; to implementation depending on the kind of interactive buffering that
;; occurs.  (The call to SLEEP here is intended to help even out the 
;; differences in implementations which do not do line-at-a-time buffering.)

So clear-input is an interface that gives you access to who knows what
sort of platform-specific functionality.

---

From: [email-masked] (Don Cohen)
Date: Sat Nov 9 09:49:03 2002

> nothing to discard. This is how CLISP behaves on Unix.

The trace output for read and clear-input clearly shows that this was 
NOT the case.

 > itself that create uncertainties in what exactly is discarded...

I disagree.  I think the CL designers knew what they were doing.
I admit that there are plenty of race conditions, but clear-input is
very useful for reducing certain errors.  It's useful precisely when 
type ahead is very likely to be wrong or dangerous.  

I was using it in a quiz program.  The program asks a question and
then reads the answer.  You can't know the answer until the question
appears.  On the other hand, if you type more answer than expected,
you're likely to be annoyed by the left over being interpreted as the
answer to the next question.