chibi-scheme
chibi-scheme copied to clipboard
ashinn
char-ready?
char-ready? generally returns #t although the next (read-char) invocation would block.
Yes, this is a known limitation... I thought it was documented somewhere.
Although looking at sexp_char_ready_p now I see nothing preventing us checking for a full char...
It would be nice if this could be made to work in 80% of the cases. In the
remaining 20%, I think one can safely return #f to make it conformant.
(Always returning #f is also conformant to the spec, I think, but pretty
useless and may break existing programs.)
Am Di., 15. Sept. 2020 um 11:01 Uhr schrieb Alex Shinn < [email protected]>:
Yes, this is a known limitation... I thought it was documented somewhere.
Although looking at sexp_char_ready_p now I see nothing preventing us checking for a full char...
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/ashinn/chibi-scheme/issues/704#issuecomment-692575544, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAHDTQ7RHYCG64R7OU5TAXTSF4UNBANCNFSM4RMZHLEQ .
Did this arise from a real-world program?
I'm not a fan of char-ready? in general. If it errs towards #f, then a program waiting for a character to be ready may get stuck, never making progress, even though a character is ready. If it errs towards #t, then a program may block when it shouldn't.
Better to use threads.
Yes, from a real-world program. A user-entered command is being parsed. As soon as the command parser (reading char by char) finds an error, the rest of the line shall be skipped. I'm currently using char-ready?. When it returns #t, I do a read-line to munch the rest of the line.
Am Sa., 19. Sept. 2020 um 16:37 Uhr schrieb Alex Shinn < [email protected]>:
Did this arise from a real-world program?
I'm not a fan of char-ready? in general. If it errs towards #f, then a program waiting for a character to be ready may get stuck, never making progress, even though a character is ready. If it errs towards #t, then a program may block when it shouldn't.
Better to use threads.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/ashinn/chibi-scheme/issues/704#issuecomment-695221013, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAHDTQ5F66D4I4L3PENF37TSGS62ZANCNFSM4RMZHLEQ .
And this actually involved an incomplete utf8 char that incorrectly blocked your program? That should be impossible for the user to input manually.
I'm not saying that my approach is the best one. I could also use peek-char to see whether the next read would be a newline (which would mean that an extra read-line would be extraneous).
So it's not crucial to fix char-ready?, although the current implementation seems to contradict the spec unless you interpret "not to hang" very liberally. :)
PS So what I would like to do is kind of flushing the input port (where the text is entered line-wise). The idea is to call read-line until char-ready? returns #f.
Having flush-input-port as a primitive could be a useful complement to RnRS flush-output-port. It could call poll() and read() in a loop until there's no data left. Since we're discarding the data, it doesn't matter whether we have a byte port or a character port. It can ignore character encoding.
I tend to agree with Alex that char-ready? is a troublesome primitive, not only in Scheme but any language that has it. byte-ready? would be simpler, but could be subsumed into a generic poll that can wait on multiple ports at once.
Common Lisp has a standard clear-input function: http://www.lispworks.com/documentation/HyperSpec/Body/f_clear_.htm#clear-input
Sorry, I may have misunderstood the problem. The current limitation is that if u8-ready? we assume char-ready?.
If your bug is not this case, can you elaborate? You just describe using char-ready? to check and then read to the end of the line, not what the apparent bug is.