[R6RS] I/O issues

[Michael Sperber]

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

> If I understand you correctly, you are proposing a side
> effect to the underlying port rather than a side effect
> to the transcoder.  While limiting such side effects to
> ports by making ports default to immutable would be an
> improvement over what was first proposed, I still don't
> understand why you are opposed to side effecting the
> transcoder instead of the port.

It has the pragmatic advantage I described:

>   This has the advantage that we can replace a settable transformer
>   by a non-settable one, letting the implementation choose an
>   appropriate buffering strategy, and forcing no buffering only when
>   a settable transcoder is replaced by another settable one.

(You say don't understand it, but that's the reason I oppose making
the transcoder mutable, as the simple interface you proposed makes the
transcoder either immutable for all time or mutable for all time.)

More fundamentally, ports *are* already mutable through the I/O
operations themselves (the term "immutable port" seems at least highly
misleading to me), whereas transcoders are descriptive objects.  I
dislike making such objects mutable, and changing a port's transcoder
seems a much more natural operation to me than changing a transcoder
components.

> Furthermore I still don't understand why you think a
> dynamic change to the transcoder should disable buffering
> on the underlying port.  Please explain.

I never said that it will disable buffering on the underlying port.  I
said it disables buffering *somewhere* where you want it.

I'll try again.  Let's say your input port has a transcoder attached
to it, and you replace it by another one, by whatever means.
Supposedly, the new transcoder needs to start transcoding at the
beginning of the data that the program has read from the port.  Now,
if the port is buffered, the implementation has two choices:

1. buffer the raw data from the input port
2. buffer the transcoded data

Choice #1 means that only as much data gets transcoded as the program
asks for.  That's possible, but it's not clear to me that it can be
done as efficiently as doing it in blocks.  (You promised benchmarks.)
With #2, you need to maintain a correspondence between the output
positions and the input positions as you don't know how much of the
transcoded data sitting in the buffer the program will read.

Regardless of what you think is a good implementation, some
implementors feel it's an issue:

http://srfi.schemers.org/srfi-68/mail-archive/msg00073.html

> (Perhaps I misunderstand, because your last sentence quoted
> above appears to talk about settable transcoders even with
> the compromise.  Please clarify.)

Whether the transcoders are mutable or the port's transcoder is
settable is irrelevant to the issue itself.  However, making the
port's transcoder settable and indicating non-settability explicitly
provides a bit more information to the port, namely whether the newly
set transcoder can itself be replaced.  This is exactly the crucial
case we've been arguing about.

The compromise I suggested would mean we wouldn't even have to talk
about the issue at all.

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