Mark H Weaver <m...@netris.org> skribis: > l...@gnu.org (Ludovic Courtès) writes: > >> Doug Evans <xdj...@gmail.com> skribis: >> >>> The problem can be succinctly represented by the following: >>> >>> scheme@(guile-user)> (port? (port-with-print-state (current-output-port))) >>> $3 = #f >> >> I think the short answer is that it’s a very old API that’s essentially >> unused internally. [...] > [...] >> I think the problem it was trying to solve has been solved differently >> (by explicitly passing the print state in the print.c code, for >> instance), and can easily be solved differently. > > In order to implement SRFI-38 properly and efficiently, I think we need > to somehow pass the print state to user-defined structure printers. > Among other things, the print state includes a map from the set of > objects that are currently being printed (i.e. the ancestors of the > current object) to the associated datum label. > > Aside from proper SRFI-38 support, the print state is also used to > specify parameters such as maximum-depth for printing abbreviated > structures, used for example by the backtrace printer.
Good points. > As distasteful as this 'port-with-print-state' concept may be, I'm not > aware of a better solution. Fluids aren't quite right, because a > structure printer might cause I/O to happen on another port. > > Another alternative would be to explicitly pass the print state to > structure printers, and then provide versions of 'write' and 'display' > that accept a separate print state argument, but we'd still need to > handle all the existing struct printers that don't know about this. > > Yet another option would be to move the print state into the port > itself. It might be worth considering, although it seems a bit unclean. Maybe the port alist you added a few months ago could be used to implement that actually, no? Thanks, Ludo’.
