[plt-scheme] curious input phenomenon

From: Robby Findler (robby at cs.uchicago.edu)
Date: Sun Jan 20 16:34:33 EST 2008

Yeah, that's exactly it. The input box can't predict the future
behavior of the program (will it read or not?) so it adopts a kind of
lazy-but-not-too-obtrusive approach: once there is a request to read
something, the box appears and it goes away when the prompt comes back
(threads complicate this a little, but if memory serves of how I
implemented it, that's how it appears in the single-threaded case).

Robby

On Jan 20, 2008 3:29 PM, Prabhakar Ragde <plragde at uwaterloo.ca> wrote:
> Chongkai Zhu wrote:
>
> > The following code explains it better:
> >
> > (define (one-last-input)
> >  (local [(define in
> >            (begin0 (read-char)
> >                    (print "\n")))
> >          (define (loop-forever)
> >            (loop-forever))]
> >    (loop-forever)))
> >
> > (one-last-input)
>
> Once I do a read, the input window is always there. I thought it
> disappeared and reappeared for the next read, but it doesn't. This code
> makes that clear:
>
> (read-char)
> (sleep 10)
> (printf "hi\n")
> (read-char)
>
> If I type "test" into the window, the #\t value appears, and the input
> box hangs around. Ten seconds later, the "hi" appears, then the #\e, and
> the input box disappears as the prompt reappears.
>
> Mystery solved. Thanks. --PR
>
> _________________________________________________
>   For list-related administrative tasks:
>   http://list.cs.brown.edu/mailman/listinfo/plt-scheme
>


Posted on the users mailing list.