[R6RS] Why `transcode-input-port!' works only once

[Michael Sperber]

I promised an explanation:

The issue came up on the SRFI list.  Here's my original response:

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

(Note the follow-up by Shiro Kawai.)

Here's the gist of it:

To work at maximum efficiency, transcoding must be done in chunks,
with some read-ahead---i.e., if somebody does `read-char', you read a
block from the input, and transcode it as a whole.  Now, let's say the
program requests to change the transcoding after it's only part of
that block---

First off, the I/O system would need to identify what position in the
un-transcoded stream the current position (of the transcoded stream)
is associated with.  This is costly, as it at least needs to backtrack
to the beginning of the block and then inch forward again bit by bit.
Worse, there may not be such a position because the port position
might be in the middle of a character, or the encoding has state that
interacts---in short, the transcoding may not be invertible.

It's possible to work around this, by creating a new port that's a
transcoded version of the old one, and turning off buffering.  (PLT
comes with a library that does this, I believe.)  This seemed to high
a price, at least for me, especially as it generally complicates the
protocol between ports layered on top of each other.  (Note this is
all much easier to handle at the streams level, where one has control
over the transcoders and how much data they remove.)

Come to think of it, I don't think there's a justification for
`transcode-output-port!' to have the same restriction.

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