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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/593eccc6-6bbf-4604-85b8-ac5f9d4ba89f%40googlegroups.com.
