[R6RS] Changing the transcoding mid-stream

[dyb at cs.indiana.edu]

> I like the one-port version better.  The plural version
> is probably a one- or two-liner using reduce-whatever.
> For convenience abbreviations like this, I'd prefer to
> let the community figure out what is most useful, write
> those things up as SRFIs, and then standardize on them
> after the SRFIs have seen some practical use.

Okay.

> No, I don't think so.  The lookahead-u8 procedure is
> supposed to block until the next byte is available or
> an apparent end of the input is seen.  Having no data
> ready is not the same as "an apparent end of the input".
> Implementations are free to represent an apparent end of
> the input however they like, but they have to buffer it
> in order to satisfy the specifications of lookahead-u8
> and lookahead-char, even if the buffer-mode is "none".

I think it is more useful for these procedures to return EOF only if the
file is still at EOF.  I can imagine implementing a nonblocking "tail -f"
by repeatedly checking for eof with lookahead-u8.  It's kind of silly to
add some mechanism to the port to handle this edge case only to force
programmers to have to call get-u8 after lookahead-u8 to consume the eof
on ports that may not be at eof permanently.

Here's a related question.  I presume that lookahead-char will raise an
exception if end-of-file is reached after some but before before enough
bytes have been read to make a whole character.  If this exception is
caught, the application continues, the underlying file is extended
independently with enough bytes to fill out the character, and get-u8 is
called again, must get-char also fail with the same exception?

Kent