[R6RS] I/O

[Michael Sperber]

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

> 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 tried to do that in the latest draft.  Better?

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

No, you're right.  I had my head somewhere the sun doesn't shine.
Your original statement quoted above is correct.  Sorry about that.

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

It's not, but I've thought this a bit and couldn't come with anything
better.  Maybe you can make a suggestion?

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

I considered that, but it is very difficult to implement efficiently.
(At least for me.)  I believe PLT's implementation of these procedures
effectively turns off buffering on the underlying port, forcing the
decoding to happen character-by-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.

OK, that can be done.  I'd still like us to decide how we want to
handle encoding errors before I invest the time required to specify
and implement this protocol.

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

I don't know that they're random: This exact model of controlling
buffering is common, for example, among SML's and POSIX's model, and
the available modes are certainly all useful.

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