Re: port-with-print-state doesn't create a port? Or, when is a port not a port? :-)

[Mark H Weaver]

address@hidden (Ludovic Courtès) writes:

> Doug Evans <address@hidden> 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.

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.

  Thoughts?
     Mark