At Fri, 29 May 2020 09:25:58 -0700 (PDT), Thomas Dickerson wrote: > 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.
The pretty print hooks apply only to `pretty-print`, `pretty-write`, and `pretty-display`. They may be most useful when implementing a printer by calling `pretty-print`, etc., instead of setting the hooks globally and expecting that pretty-print` is used. > > 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) It's possible to globally extend `read` via a readtable, but there's also `call-with-default-reading-parameterization`, which various libraries use to make sure they have the default reader settings (e.g., when reading a preferences file). There's not currently anything that libraries can use like `call-with-default-writing-parameterization`, which means that globally changing `write` could break libraries. Meanwhile, it's possible to change the `print` function more globally through `global-port-print-handler`. Finally, there's `display`. I think `display` in principle should be more configurable, because it's meant to about how things are displayed for humans to read. These different approaches, with a relatively flexible reader and and a relatively inflexible writer, evolved as a result of various pressures. I think the write side is a little closer to right idea with its distinction between `write` for serialization, `print` for displaying values, and `display` for showing things for humans. (On the read, side, we could have done better by making a cleaner separation between `read` and `read-syntax`. Still, it's complicated.) I think a variant of your PR that just affects `display` may be ok, and it would be worth exploring if that solves a problem. Given that `print` and `display` seem safely configurable, the question is whether you want to modify `write` just because that's a third printing function or because it's important in your target use. If, for example, your language wants to provide a `write` that isn't the Racket serialization write, it can always provide a different function as `write`. That won't affect other libraries that may be called by programs in your language, but my point is that it generally shouldn't; those libraries should be using `write` for serialization-type purposes. At Fri, 29 May 2020 13:24:17 -0700 (PDT), Thomas Dickerson wrote: > Quick follow-up: > It looks like I may somehow be able to change DrRacket's printing and > reading behavior on a per-language basis somehow using the classes here I don't think you want that layer of tools. At the DrRacket layer, you want to stay in the `#lang` world --- so, don't do anything DrRacket-specific. At the level of the `#lang`/module system, a language can parameterize run-time functionality, such as the reader and printer, through a `configure-runtime` submodule. See https://docs.racket-lang.org/guide/module-runtime-config.html and https://docs.racket-lang.org/reference/running-sa.html#%28part._configure-runtime%29 So, that's the place where you'd update the reader, printer, and displayer. > 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. >From a language implementation perspective where you're setting the global print handler to use `pretty-print`, your language gets to set the starting point, and libraries as used by programs in your language can cooperate with it by extending (instead of replacing) the printer. So, I think you'd want to make the language use `pretty-print` and recur as needed (which is not at all for just changing numbers) to allow library-based extensions. At Fri, 29 May 2020 17:06:14 -0400, Thomas Dickerson wrote: > Interesting - does the default #%top-interaction behave differently from > #%module-begin w.r.t. to a #lang's read? > Right now my main.rkt is providing the standard #%module-begin, > #%top-interaction, #%app, #%datum, and #%top, in addition to my language's > functions + macros. Yes, those are at the macro layer, and they don't have anything to do with the reader. (Although it may be possible to make `#%top-interaction` have a useful side effect on the printer, it's not the direction to go.) -- 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/20200603121658.1f3%40sirmail.smtp.cs.utah.edu.
