On Friday, May 29, 2020 at 11:29:38 AM UTC-4, Matthew Flatt wrote: > > DrRacket uses `pretty-print`, which will print numbers using > `number->string`, and so (I think) won't go through your parameter. >
This sounds like a good lead - curious if this also applies to `write` and `display` as well? I was having trouble with all three. > I think there may be problems with parametering the core printer, > partly because printing is is sometimes used where `read` is supposed > to work on the result, but I think there may be other issues and I > haven't thought through them enough. > The intended use is in a setting where `read` has already been extended (cf. my original question in this thread, which is that the DrRacket interactions window appears to ignore any `read` extensions provided by a #lang) > Just to make sure, does using the pretty printer and its hooks > (especially `pretty-print-print-hook`) work for your goals? > It sounds like that may be useful for fixing this particular issue with DrRacket, but I don't think it will meet my goals for the overall project. One question - to what extent are pretty-print-print-hooks expected to cooperate with the current value of that parameter when printing compound or recursive values? It would be great to install a hook that delegates to the existing hook for everything but numbers, but that approach not working with port-print-handler et al. is what led me to parameterizing over all of print et al. For example, if for some reason I want numbers to be printed as Roman numerals, I don't want to reimplement printing lists for `(print '(7))` to result in `'(VII)` -- 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/593eccc6-6bbf-4604-85b8-ac5f9d4ba89f%40googlegroups.com.
