Mark H Weaver <m...@netris.org> writes:
> For example, I recently discovered that REPL Servers weren't redirecting
> the warning port to the socket, so warnings about expressions typed on a
> REPL server were being sent to the main program's stderr. I fixed this
> in 5e74217c7cf07ad474cdce1a01e049492e7ef1b7, but if we add another port
> parameter I'll have to fix that in at least two places now: server.scm
> and coop-server.scm.
>
> I wonder if external code needs to sometimes do this as well. How will
> they cope with a periodically-expanding set of port parameters, while
> retaining compatible with older versions of guile that lack some of
> them? Should we add a 'parameterize-all-stdout-like-ports' macro?
It occurs to me that one possibility would be to allow some of these
parameters to effectively mirror the value of some other parameter.
For example, the 'current-notification-port' parameter could mirror the
'current-warning-port' parameter by default, which could in turn mirror
the 'current-error-port' parameter by default.
One way to implement this would be to make the corresponding fluid be a
thunk that returns a port, instead of the port itself. The converter
could accept either a port or a parameter, and convert each of these to
a suitable thunk. Finally, we'd make custom 'current-warning-port' and
'current-error-port' procedures that would handling calling the thunk.
Of course, this extra complexity would make these parameters inherently
more expensive, so it would only be appropriate for these special
seldom-used port parameters. However, for these cases it might be a
worthwhile extension. In one commit we could fix a number of possible
bugs (similar to the one fixed by 5e74217) that might well exist in
external code.
What do you think?
Mark
