[plt-scheme] MzScheme and read-line

From: Eric Swenson (eric at swenson.org)
Date: Fri Oct 2 14:57:58 EDT 2009

Not to belabor the point, but if you write code using my-read-line, it will
work in MzScheme, but not in DrScheme.  (And, conversely, if you write code
using the normal read-line in DrScheme, it will not work in MzScheme).  This
seems non-optimal! -- Eric

On Fri, Oct 2, 2009 at 11:52 AM, Eric Swenson <eric at swenson.org> wrote:

> Thanks, YC.  I will give this a try. Note, however, that if I found this
> confusing, others will too. This is a difference in behavior from running
> under DrScheme and MzScheme.  I would recommend that it be documented
> somewhere.  -- Eric
>
>
> On Fri, Oct 2, 2009 at 11:50 AM, YC <yinso.chen at gmail.com> wrote:
>
>>
>>
>> On Fri, Oct 2, 2009 at 9:23 AM, Eric Swenson <eric at swenson.org> wrote:
>>
>>>
>>>
>>> On Fri, Oct 2, 2009 at 9:21 AM, Eric Swenson <eric at swenson.org> wrote:
>>>
>>>> Hello Chongkai,
>>>> Thanks for your suggestions.  I tried this, but it didn't work.  In the
>>>> case where (read-line) is returning "\r", I note that read-bytes-avail!* is
>>>> returning 0, yet a subsequent read-line still returns "\r".  (I tried your
>>>> example code exactly, and my-read-line returns "\r" as well.)  I wonder if
>>>> this is a Win32 issue (line-ending issue) where some of the win32-specific
>>>> support is not stripping the "\r" from the end-of-line sequence "\n\r"?
>>>>
>>>
>> The line ending on Windows is \r\n instead of \n\r.  The reason you have
>> \r returned is because (read-line) as is by default only use \n as a
>> terminator, so when it sees \r\n it thinks \r is the data and returns it (on
>> Unix it only sees \n, so the data is "").
>>
>> Use (read-line (current-port) *'any*) instead of just plain (read-line)
>> will treat \r\n as a single terminator.
>>
>> As Chongkai said - when you type (read-line)<enter> the reader will
>> consume the (read-line) but leaves <enter> in the buffer, which read-line
>> then consumes, so you need a function that has two read-line calls, the
>> first will consume the left over, and the second will then wait on input.
>>
>> (define (my-read-line)
>>   (read-line (current-input-port) 'any)
>>   (read-line (current-input-port) 'any))
>>
>> Since this specifically tackles the behavior of REPL - it has limited
>> applicability elsewhere.
>>
>> Cheers,
>> yc
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.racket-lang.org/users/archive/attachments/20091002/a1a0f14e/attachment.html>

Posted on the users mailing list.