[r6rs-discuss] [Formal] string output ports

From: R. Kent Dybvig <dyb>
Date: Tue Jan 23 10:50:22 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
    new interface.

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

Kent
Received on Tue Jan 23 2007 - 10:49:38 UTC