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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/20200603121658.1f3%40sirmail.smtp.cs.utah.edu.
