[plt-scheme] curious input phenomenon

You are fooled by DrScheme's input port. If you check the CPU useage of 
DrScheme, you will notice that DrScheme start to use 100% of the CPU 
after it get the first char. The loop-forever is looping, but the input 
port will still be available in the interaction windows (until REPL need 
to read again).

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)


Chongkai


Prabhakar Ragde wrote:
> When I run the following program in DrScheme, v372, Pretty Big:
>
> (define (one-last-input)
>   (local [(define in (read-char))
>           (define (loop-forever)
>             (loop-forever))]
>     (loop-forever)))
>
> (one-last-input)
>
> it offers me an input box in the Interactions window. I enter some 
> text and press Enter. It offers me another box, and keeps doing so 
> until I press EOF, at which point it just hangs (predictably). What I 
> don't understand is the extra input boxes. Putting a print statement 
> into loop-forever seems to indicate that the input boxes are being 
> offered concurrently with the execution of the infinite loop. Why is 
> this happening? Thanks. --PR
>
> (I discovered this because a student, learning about I/O, wrote a 
> program like the previous one except that the infinite loop was an 
> accident, not intentional. I could give them a hint as to how to fix 
> their program, but I was at a loss to explain the observed behaviour.)
> _________________________________________________
>  For list-related administrative tasks:
>  http://list.cs.brown.edu/mailman/listinfo/plt-scheme