[R6RS] incomplete draft of revised i/o

[William D Clinger]

Mike wrote:
> You elided the "descriptor" argument to the custom port creation
> procedures.  Is it still possible to implement string ports and other
> custom ports, where the custom sink or source needs to be accessed
> externally, in a natural way?

No.  That didn't seem to be a requirement, and wasn't
listed as a use case, so I opted for simplicity.  You
can implement string-port-like and custom-port-like
things, but the input-port? and output-port? predicates
won't recognize and the standard i/o procedures won't
work with them.

As I understood the requirement, it was to implement
ports with arbitrary byte sources and sinks.  The
simplified make-binary-X-port procedures satisfy that
requirement.

By the way, I don't think make-binary-input-port and
make-binary-output-port are good names for these
procedures.  Please suggest something better.  (Maybe
make-input-reader-port and make-output-reader-port
would be better.  I don't know.)

> (The easiest way I know is to put the
> descriptor back in and provide an accessor for it.)

The easiest way I know to make the port type extensible
is to require ports to be an extensible record type.
My current theory for the purpose of that descriptor
is that it served as a poor man's row variable,
allowing arbitrary state to be tacked on to the port.

If you want the port type(s) to be extensible, it would
be better (IMO) to use inheritance.  Nothing in the new
i/o proposal would preclude such extensibility in some
future version of the report.

> > I still haven't changed bytes objects to bytevectors, though.
> 
> Should I do that?

If you want to.  Otherwise I'll do it this afternoon or
evening, after I've read enough of the new draft to figure
out the naming convention for bytevector parameters.

Will