[R6RS] incomplete draft of revised i/o

[William D Clinger]

I have just checked in a new revision of the i/o chapter
in which bytes objects have been renamed to bytevectors.
There are several issues with this revision, which I will
discuss in increasing order of importance.

formatting
==========

Several of the prototypes extend too far to the right.
It would be easier for the project editor to fix this
than for me to figure out how to fix it.

file-options
============

It seems to me that (file-options) is the wrong default
when you open an output file.  I added a sentence that
says this, but it would be better to fix the problem.

port-magic
==========

I added a magical mystery proc to every port.  This
magical mystery proc makes it possible to implement
string ports as custom ports (which was essentially
impossible in the 5.91 draft and in SRFI-81), but
it's a fragile hack.  On the other hand, the magical
mystery proc isn't quite as fragile as the reader/writer
descriptors of 5.91 and SRFI-81, and it is substantially
more powerful.  There are several things that I think
are important for the editors to understand about this
magical mystery proc.

First of all, we could remove the magical mystery proc
and still be able to construct any custom ports that
could have been constructed using 5.91 or SRFI-81.
The proof of this fact is that the only way to build
a custom port using 5.91 or SRFI-81 was to use one of
the following procedures:

    open-reader-input-port
    open-writer-output-port
    open-reader/writer-input/output-port

The ports you got from these procedures encapsulated
a reader or writer or both.  An operation that is
passed the port as an argument would not be able to
get at the encapsulated reader or writer, so it would
not be able to get at the descriptor of the encapsulated
reader or writer.

To work around this problem, a programmer could
maintain some kind of weak hash table that maps
custom ports to the readers and writers they
encapsulate, but that same kind of semi-solution
would work even if readers and writers didn't have
descriptors: you'd just have the weak hash table
map custom ports to descriptors.  Furthermore that
same kind of semi-solution would work with the new
i/o proposal even if we were to remove the magical
mystery proc!  You'd just have the weak hash table
map custom ports to magical mystery procs.

The magical mystery procs of the current draft are
somewhat fragile, but they aren't as fragile as the
weak hash tables or other equivalents you'd have to
use with 5.91 or SRFI-81.  In particular, you can
cook up uniquely recognizable arguments to the
magical mystery procs just as easily as you could
cook up uniquely recognizable descriptors, so that
part is a wash.  The magical mystery procs are less
fragile than descriptors because they get rid of the
extra machinery (the weak hash tables or equivalent
hacks).

The next thing I want to say is that the ability to
implement string ports (etc) as custom ports has not
been a stated requirement of this i/o system, and
had not until recently been stated as a use case for
the i/o system.  Had it been a requirement, neither
5.91 nor SRFI-81 would have satisfied that requirement
in any reasonable sense.  Any belief to the contrary
is simply incorrect.

The bottom line is that, in my humble opinion, the
magical mystery proc is a feeping creature as well
as a hack.  The magical mystery procs are in the
current draft for four reasons: (1) to show that we
could design a system in which string ports (etc)
could be implemented as custom ports; (2) to point
out that string ports (etc) could not have been
implemented as custom ports in 5.91 or SRFI-81;
(3) to point out that the readers and writers of
5.91 or SRFI-81, even with their descriptors, were
not adequate for implementing arbitrary custom
ports; and (4) to point out that the current draft,
even without the magical mystery proc, would be at
least as good as 5.91 or SRFI-81 when it comes to
implementing arbitrary custom ports.

I would like to remove the magical mystery proc
from the i/o chapter, and I hope the other editors
will agree to that removal.

Will