[R6RS] incomplete draft of revised i/o

[R. Kent Dybvig]

> > I agree with Will that the magical mystery procedure should be eliminated. 
> > I would go further and change the interface to string and bytevector
> > ports, i.e., have the string and bytevector output port creation routines
> > return two values:  a port and a procedure.  The procedure would be used
> > to get the output.  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 magical mystery procedure.
>
> That would also be acceptable for me.

Okay.  I haven't heard any objections, so I'm going to assume this is okay
with everyone else as well.

I've committed a new portio.tex that eliminates the magic argument and
makes the string/bytevector-output-port interface change described above. 
In particular:

  - open-string-output-port returns two values: a port and a procedure.
    the procedure is called to obtain a string consisting of the
    accumulated data and removes the accumulated characters from the port.

  - open-bytevector-output-port returns two values: a port and a procedure.
    the procedure is called to obtain a bytevector consisting of the
    accumulated data and removes the accumulated data from the port.

  - get-output-string and get-output-bytevector are gone

  - clear-string-output-port! and clear-bytevector-output-port! are gone

  - call-with-string-output-port and call-with-byte-vector-output-port
    work as before, except they aren't closed on return but merely
    have their accumulated characters/data removed so that returning
    more than once is meaningful.

There are only two points of contention I anticipate:

  1. whether calling the procedure returned by
     open-{string,bytevector}-output-port clears the accumulated data or
     not.   I think it's simple and clean for it to do so, but we could
     consider allowing the procedure to take an "clear" boolean argument,
     possibly optional and defaulting to either #f or #t, I don't care
     which.

  2. whether call-with-{string,bytevector}-output-port should just
     remove the accumulated characters/data or (as previously specified)
     actually close the port.  I don't see a downside to merely removing
     the accumulated data and thus allowing the procedure to return
     multiple times, but perhaps someone else does.

If someone objects and we revert back to the portio before I started making
these changes, please note that the old description of
call-with-string-output-port mentioned a \var{transcoder} argument even
though it's prototype doesn't have one.

Kent