Closed AlexKnauth closed 9 years ago
I've seen e.g. Typed Racket define #%top-interaction
to provide REPL behavior like printing the type of the result.
But IIUC #%top-interaction
is too late in this case -- the read has already happened?
I forget, had you asked about this on the Racket mailing list? Our use case doesn't seem very unusual. Maybe there's some other way to accomplish this. Or if not, Racket could add this? Otherwise it seems like a small but significant hole in the "language for making languages" story.
I can't believe I overlooked this! This is a great improvement. Merged; thanks!
Oh, I did something similar for at-exp, but elibarzilay commented and said it might be better to just update the readtable (once) instead of updating current-read-interaction to be a function that creates a new readtable every time. So do you think it would be better to do that, or keep this? see: https://github.com/plt/racket/pull/811#issuecomment-61992444 https://github.com/plt/racket/pull/811#issuecomment-62090573
Ah, OK. So you mean that the lang/runtime-configure.rkt
could be simplified as in https://github.com/AlexKnauth/racket/commit/e972753b59755c3a0ff457748371d48e0a37a5ed ?
From this:
(define (configure data)
(define old-read (current-read-interaction))
(define (new-read src in)
(parameterize ([current-readtable (make-lambda-readtable (current-readtable))])
(old-read src in)))
(current-read-interaction new-read))
To just this:
(define (configure data)
(current-readtable (make-lambda-readtable (current-readtable))))
Is that correct?
Yes, if you think it's a good idea.
Done with commit 05e57f7. Thanks again!
see https://github.com/greghendershott/rackjure/issues/45 One reason not to do this is that if a rackjure module is required from a non-rackjure module, it will still update the current-readtable, so the current-readtable in the non-rackjure module would be affected.
Edit: Using either a configure-runtime submodule or the #:language-info option and a runtime-config.rkt avoids this problem.