[r6rs-discuss] [Formal] string output ports
R. Kent Dybvig
dyb at cs.indiana.edu
Tue Jan 23 10:49:38 EST 2007
> Hidden amongst all the welcome changes to the i/o system
> were some less welcome changes to string output ports.
> First of all, the open-string-output-port procedure still
> requires a useless proc argument.
Technically, this is a less welcome non-change. It should be fixed.
> More importantly, the string ports of version 5.91 were
> compatible with the string ports of SRFI 6 in the sense
> that either could be implemented in terms of the other
> with little effort. The string output ports of version
> 5.92 are no longer compatible with SRFI 6, because there
> is no way to implement the get-output-string procedure
> of SRFI 6 using operations of version 5.92.
> No rationale for this change has been offered, and the
> editors' email discussions (which, SFAIK, are not yet
> public, else I would cite the thread that somehow led
> to this change) contain no serious argument for it.
I think Will is referring to this, which I wrote:
> This interface would be just as easy to use in all of
> the code I have that uses string output ports, it reduces the complexity
> and number of procedures in the report, and it can be implemented without
> the [descriptor argument].
Let me expand so that, if not Will then perhaps others will recognize the
seriousness of the arguments for the change.
- The new interface requires fewer library procedures:
- The get-output procedures have been subsumed by the procedure returned
by the open routines and have been eliminated.
- Since the output is cleared in the new interface when the data is
extracted from the port, the clear-output procedures are also unnecessary
and have been eliminated.
(This change is orthogonal to the rest, and I recommend it even if we
revert back to the old interface. If, on the other hand, there is a
perceived need to control this behavior, it is easy to add a boolean
flag, perhaps optional, to the procedures returned by the open
routines that determines whether the output is cleared.)
- As we've done in other areas of the language, we should also have had
bytevector-output-port? and string-output-port? predicates to protect
calls to the get-output procedures. These were missing and should be
added if we revert to the old interface. They are not needed with the
- Conceptually, it's cleaner not to have these different kinds of ports.
With the new interface, a bytevector- or string- output port is
conceptually the same as any other port.
- The new interface is compatible with the new mechanism for creating
custom output ports. (The old interface is not, unless we include
something like the R5.91RS primitive-I/O descriptor argument in the
custom port mechanism.) This is a nice bit of conceptual harmony. It
also gives programmers a model for creating similar abstractions with
their own custom ports.
While I agree that the new interface cannot be used to implement SRFI 6's
get-output-string and similar mechanisms that predated SRFI 6 in some
Scheme implementations (including Chez Scheme), I do not see this as a
serious drawback. There are other features of other SRFIs that cannot be
implemented using features built into R5.92RS, and I'm not aware that
remedying this situation is a goal of R6RS.
On the other hand, the interface is not inherently incompabible with SRFI
6; an implementation can provide both the R5.92RS mechanism and the SRFI 6
More information about the r6rs-discuss