Formal comment #148 (defect)

String output ports are even more broken now
Reported by: 	William D Clinger
Version:	5.92

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.

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 recommend that the operations on string output ports revert to their
specification in version 5.91, modulo corrections, removal of optional
transcoder arguments, and any other changes that may have been made
necessary by improvements to the rest of the i/o system. The editors'
Subversion repository contains a proposal along these lines, and the
editors' email archive contains a correction to that proposal.

Will


RESPONSE:

The "useless proc" argument will be removed in the next draft.
As to the other changes, they were made for the following
reasons:
 
- 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.)

- 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 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, the interface is not inherently incompabible; an
implementation can provide both the R5.92RS mechanism and the SRFI 6 (or
similar) mechanism.