The dev team will have to answer your actual question, but I thought I
might offer a more compact solution that incorporates the fix you mentioned:
(define (yn #:read-one-char? [read-one-char? #f])
(display "y/n: ")
(flush-output (current-output-port))
(define func (if read-one-char? read-char read-line))
(match (list (func) (func))
[(list _ (or #\y #\Y "y" "Y")) #t]
[_ #f]))
On Fri, Sep 24, 2021 at 3:01 PM Winston Weinert <wins...@ml1.net> wrote:
> Hey everyone,
>
> I was working on a procedure to prompt the user for confirmation and found
> something a bit strange - it did not appear to read for input when usingt
> "racket -i" or in the Emacs Racket REPL buffer. Here is the code:
>
> (define (yn #:read-one-char? [read-one-char? #f])
> (display "y/n: ")
> (flush-output (current-output-port))
> (if read-one-char?
> (match (read-char)
> [(or #\y #\Y) #t]
> [m #f])
> (match (read-line)
> [(or "y" "Y") #t]
> [m #f])))
>
> Regardless if I use read-char or read-line and type y or Y, the behavior
> seeims
> similar, each of the match's second clause is followed because (read-char)
> returns #\newline whereas read-line returns "" (empty string).
>
> I mentioned this strange behavior on the Libera chat and got an
> enlightening
> response from tonyg outlining what is happening:
>
> > at the repl, if you type "(read-char)" and press enter, the reader sees
> ( r e
> > a d - c h a r ) NEWLINE. When it gets to the close-parenthesis, it
> executes
> > the expression, which reads the NEWLINE character and returns. Similar
> for
> > read-line, where it sees NEWLINE and returns an empty line
> >
> > try typing (list (read-line) (read-line))
>
> I can confirm tonyg's solution works. The (list (read-char) (read-char))
> also
> appears to work, though one always has to type a final newline to send the
> line-buffered input.
>
> The behavior feels very surprising and took me a bit of time to figure out,
> even then I didn't really understand it so I had to ask for help. Can this
> behavior be changed in a future release? Is a reasonable request or could
> this
> break a lot of code? If this could break stuff, is it worth doing
> changing it
> anyway, so the behavior is less surprising? I hope to understand if it's
> agreeable to make a PR for this change before investing the time.
>
> Keep on Racketing!
>
> Winston Weinert
> winny.tech
>
> --
> You received this message because you are subscribed to the Google Groups
> "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to racket-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/racket-users/20210924190134.mjxttwqtgeunjbus%40ml1.net
> .
>
--
You received this message because you are subscribed to the Google Groups
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to racket-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/racket-users/CAE8gKoeXrgNa%2BAkUgbX4sBi77y7wPM0AhRLvrwVfrtKTAyaPCQ%40mail.gmail.com.
