[R6RS] Changing the transcoding mid-stream

[William D Clinger]

Kent wrote:
> > > Should we consider:
> > >   (call-with-ports proc port ...)
> > > or
> > >   (call-with-ports list-of-ports proc)
> > > instead of or in addition to call-with-port?
> >
> > Those can be written as macros.  If people find them
> > useful, they can write a SRFI for them.
> 
> I was actually thinking of a procedure, probably replacing the one-port
> version.

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.

> Good points.  This raises a question: If a call to lookahead-u8 returns
> eof, and the next operation on the port is a call to get-u8 or
> lookahead-u8, can the second call return something other than eof if the
> underlying file (or whatever) has been extended in the meantime?

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

Maybe the description of buffer-mode should point this
out.

> clear-input-port discards any buffered input; there's no where to flush
> it to.  It's useful in error handlers when reading input from the user
> to avoid mistaking earlier typeahead for an answer to a query.

Now that I understand the semantics, I'd prefer to call
it flush-input-port.  Those who believe in a law of
conservation of data can also believe in the bit toilet.

> clear-output-port discards any buffered output.  I haven't found much use
> for it.  I suppose if the computer is on fire, and you want to get the
> message out quickly, you might want to discard any pending output first.

I don't see how there could be any portable use for this,
and it would call into question my preferred name for the
flush-input-port procedure, so I'm inclined to oppose it.

Will