[plt-scheme] (thread read)

So the:

 >> > (in DrScheme, even different from run to run).

is to be explained by the new thread reading old input?

Or ... hmmm.

/Jens Axel




Robby Findler skrev:
> As it turns out, drscheme doesn't quite do that. Drscheme separates
> the user input from the REPL input and, in the program below, actually
> never sends anything to the thread, because the printing of a new
> prompt erases the input box.
> 
> This is because DrScheme's REPL doesn't read from current-input-port
> 
> But, that's what happens in mzscheme or mred's repl (or in other
> contexts) -- only drscheme's repl is special.
> 
> Robby
> 
> On 6/7/07, Jens Axel Søgaard <jensaxel at soegaard.net> wrote:
>> Chongkai Zhu skrev:
>> > What is
>> >
>> > (thread read)
>> >
>> > suppose to do? Trying on both DrScheme and MzScheme, version 370 
>> [3m], I
>> > got different effects (in DrScheme, even different from run to run).
>> >
>> > Doing more experiments in DrScheme only confuse me more. Could anyone
>> > help clarify? Thanks.
>>
>> The original thread (the REPL) and the new thread share the input port.
>> When you type something at the REPL either the REPL *or* the new thread
>> will read it. If the thread reads it, nothing happens. If the
>> REPL reads it it gets evaluated as usual.
>>
>> If the REPL reads part of an expression and the threads read some
>> then...
>>
>> Compare:
>>
>> (parameterize
>>      ([current-input-port
>>          (open-input-string "This is read by the thread")])
>>    (thread (lambda ()
>>      (display (read)))))
>>
>> -- 
>> Jens Axel Søgaard
>>
>> _________________________________________________
>>   For list-related administrative tasks:
>>   http://list.cs.brown.edu/mailman/listinfo/plt-scheme
>>
> 
> ------------------------------------------------------------------------
> 
> _________________________________________________
>   For list-related administrative tasks:
>   http://list.cs.brown.edu/mailman/listinfo/plt-scheme