[R6RS] I/O

[William D Clinger]

Mike wrote:
> > Now do you understand why I am mystified by your argument?
> 
> No.  Maybe you could try sketching how you would implement byte
> writers using simple writers---specifically, how you would implement
> `writer-bytes', without the descriptor fields in the simple writer.

>From reading the document and what you have said so far,
I cannot even construct a legal call to make-simple-writer
because I do not know what kinds of objects are acceptable
as the second argument.

> > I wrote "It may be that any object whatsoever may be passed
> > as the descriptor", but you have neither confirmed nor
> > denied that possibility.
> 
> I guess I've been unclear on that---sorry about that.  If I wrote a
> statement to that effect, would it help?

If it's true, then stating that it is true would help.
If it's false, then stating that it is false would help,
but you would still have to explain what kind of objects
are acceptable as a descriptor.

> > I would guess that you are assuming a model in which some
> > character, e.g. END OF TRANSMISSION, popularly known as
> > control-D, is interpreted as an end of file when typed.
> 
> No.  I'm assuming a model where the other end sends a block of data
> and then pauses temporarily (i.e. stops typing).

Wow.  Please confirm:  You are assuming a model in which
a call to read-u8 (for example), with an interactive input
port as argument, will return an end-of-file object if no
data is available from the port?

How do you reconcile that with the specification of read-u8
("blocking as necessary, until data is available from
input-port or the next end of file has been reached")?

> > In that model, peek-byte would hang if no data is available, but
> > would return an eof-object only if the interactive port is closed.
> 
> That would provide less information to the programmer, as the program
> might want to get data up to the point where the other end stopped
> transmitting temporarily, and then do something as opposed to
> blocking.

You really do sound as though you are assuming a model that
is inconsistent with the specification of read-bytes-some,
read-u8, read-bytes-n, read-bytes-n!, read-bytes-all,
read-char, read-string-n, and read-string-n!.

In constructing that list, however, I just now noticed that
read-string-all does not block, but returns an end-of-file
object if no data is available.  This appears to be the only
procedure whose specification is consistent with the model
you appear to be claiming to assume.  Do you think you agree
with this guess?

> > I would strongly prefer that the R6RS not make any closed
> > world assumptions.  Without such assumptions, it will be
> > possible for implementations to add other procedures that
> > support nonstandard textual i/o of arbitrary weirdness.
> > In other words, I don't know of anyone who is proposing
> > any restriction of textual i/o to supported standards.
> > I, however, propose that R6RS i/o support only supported
> > standards.
> 
> You seem to be.  You advocate eliding `transcode-port!', which takes
> away from the programmer the only possibility for specifying the
> encoding after having read data.

The only reason that is the only possibility is that it
is the only means provided by this particular proposal.
I do not accept your implicit assumption that this is
the only possible means that could be provided.

> If you want to avoid a closed-world
> assumption, it would be good if you specified how you would like the
> interface to look.

I believe I suggested an alternative some time ago: provide
a procedure that takes an input port and a transcoding, and
returns an input port that uses the transcoding.  The original
input port could still be used with its original transcoding
(if any); although this would require care in programming, it
is a more general and more powerful model than the side effect
you have been advocating.

> > In my opinion, the simplest and cleanest solution is to
> > raise a specific continuable exception.  That would catch
> > the error condition (and this is truly an error condition,
> > much more so than some of the other things for which we are
> > insisting an exception be raised), while allowing programs
> > to install exception handlers that ignore the situation or
> > replace the situation by whatever character(s) they like.
> 
> The last bit is the hairy one: How do you allow the exception handler
> to replace the character?

Every continuable exception must be accompanied by a protocol
that describes how the exception can be continued.  In this
case, I propose that an exception handler that wishes to
ignore the situation simply return zero values, and that an
exception handler that wishes to replace the situation with
some sequence of replacement characters simply return those
characters.

> > The more performant Scheme systems have found ways to make
> > byte-by-byte i/o quite fast.
> 
> I have no doubts about the "quite."  I have doubts that it can be made
> as fast as block I/O, especially if no buffering is being used.

The point is that buffering *can* be used, and will be more
effective if implementations are allowed to design their own
protocols than if they are required to support random things
like set-output-port-buffer-mode! on every port.

Will