[R6RS] I/O

[Michael Sperber]

William D Clinger <will at ccs.neu.edu> writes:

> Since this example is supposed to motivate the descriptor
> argument of make-simple-writer, I assume you meant to say
> that open-bytes-writer could create the writer it returns
> by calling make-simple-writer. 

Yes.

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

> 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?

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

> I would prefer a model of interactive ports that does not
> impose any such interpretation upon legitimate Unicode
> characters, and delivers an end of file object only when
> the interactive port is closed, e.g. by a procedure such
> as close-input-port.

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

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

> 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?

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

-- 
Cheers =8-} Mike
Friede, Völkerverständigung und überhaupt blabla