Mark H Weaver <m...@netris.org> skribis: > 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?
Yes, it seems like it should work, and I find it natural. We’d have to check on a concrete use case. Ludo’.
