The intention here is that you should have a notion of an expression that is itself consistent and you should read until you get a whole one of those and then just return that. The different behavior you see in DrRacket and at the terminal window prompt will, yes, cause different behavior, but it isn't supposed to be something that you would explicitly check for and respond to.
In the case of the DrRacket window, DrRacket makes the assumption that your expressions will be terminated by an EOF and puts those into the port between each submission that the user makes in order to support things like typing alt-return (something that doesn't happen at the terminal window). Robby On Mon, Jun 6, 2016 at 11:09 PM, Alexis King <lexi.lam...@gmail.com> wrote: > I am trying to write a custom current-read-interaction for a language > with non-s-expression syntax, and I’m not sure I completely understand > the protocol for how to detect the end of input across both the command > line and DrRacket. I first wrote an implementation for DrRacket, which > appears to continually call current-read-interaction until it returns > #<eof>, at which point it presents the user a new prompt. Therefore, I > simply decided to check char-available? on the provided port and return > #<eof> whenever the port returned #f. This seems to work fine in > DrRacket. > > On the other hand, I found it does not work at all on the command line. > Returning #<eof> on the command line just seems to kill the entire REPL. > Furthermore, unlike DrRacket, the CLI does not seem to produce an EOF at > the end of each expression, just a newline, re-using the same port each > time. Checking for a newline in DrRacket would not work at all, though, > because DrRacket permits entering multiline expressions in its REPL. > > This would lead me to believe that there are two completely different > protocols for how the two different REPLs work: > > 1. In DrRacket, read all the contents in the port provided to > current-read-interaction. Check the port against char-available? > each call, and return #<eof> when it returns #f. > > 2. At the command line, read all contents up until a newline. Check > the port against peek-char each call, and return #<eof> when it > returns #<eof> to support exiting the REPL by sending ^D. > > These seem totally different, frustratingly so, since it seems like it > would not be too hard for the CLI to use the same behavior as DrRacket. > My guess is that I’m overcomplicating things at least a little, but I > wasn’t able to locate anything about what exactly is expected of the > function provided to current-read-interaction. Is there a way to > implement it that can gracefully handle both scenarios? If not, what is > the proper way to check if code is running in the CLI REPL or the > DrRacket REPL and adjust behavior accordingly? > > Alexis > > -- > 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. > For more options, visit https://groups.google.com/d/optout. -- 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. For more options, visit https://groups.google.com/d/optout.
