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

[Mark H Weaver]

I wrote earlier:

> 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.

Having thought more on this, I think fluids might be the right tool.

The only detail is, the print state would have to include a reference to
the associated port.  Then, if the port passed to 'write' or 'display'
doesn't match the one associated with the current-print-state, it would
be saved and later restored, with a fresh new current-print-state used
for the duration of that 'write' or 'display' call.

What do you think?

      Mark