[R6RS] Changing the transcoding mid-stream

[William D Clinger]

Kent wrote:
> (buffer-mode name), (buffer-mode? obj)
>   - does it really return a symbol ("returns the corresponding symbol")?

Yes, buffer-mode returns a symbol.  I'll simplify the wording.

>   - does (buffer-mode line) evaluate to line?

Yes.

> Is update-transcoder actually useful?

Possibly.  There is no standard way to query a transcoder's
components, so update-transcoder is the only to obtain a
transcoder that is like some arbitrary given transcoder
except for its eol-style, or except for its codec.  (Note
that both the codec and eol-style are optional.)

That said, I wouldn't mind flushing this syntax.

> (eol-style name), (eol-style? obj)
>   - "lf" is shown twice---should one occurrence be "cr"?

Yes.  That typo was in port-io-srfi.html and I forgot to
fix it.

>   - does this really return a symbol

Yes.  I'll simplify the wording.

>   - does (eol-style lf) evaluate to lf

Yes.

> I assume that each of utf-8-codec, latin-1-codec, etc., are procedures

Yes.

> port-has-position?, port-has-set-port-position!?
>   - these names are inconsistent---rename first "port-has-port-position?"

Done.

>   - answer to FIXME question in both cases is yes: standard-input and
>     standard-output may not support port-position

Okay.  I'll remove those questions.

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

> port-eof? can return a bogus result if someone else is appending to the
> file, or force peek-char to return a bogus result.

That's life.

Both lookahead-char and port-eof? can return misleading
(but not bogus) results if someone else is just reading
from the port.

> Of less importance: to implement port-eof? at all under Unix will
> require a "I peeked an eof" flag in the port object (because of "broken"
> tty behavior discussed on the mailing list).

I think the machinery for that is already required by the
semantics of lookahead-u8.

> We decided to eliminate close-input-port

Done.

> Should we include a clear-input-port procedure?
>  - useful in error handlers

Shouldn't this be called flush-input-port?  If not, then
I don't understand its semantics.  (You can't make
bytes that were read previously disappear.)

> We decided to eliminate close-output-port

Done.

> Should we include a clear-output-port procedure?

I don't understand the semantics of this either.  (You
can't make bytes that were written previously disappear
unless the output port corresponds to something like a
file.  Maybe a port-has-clear-port? procedure would go
along with this.)

> Why do we have only call-with procedures for bytes and string output ports
> but only open- procedures for bytes and string input ports?

Good question.

I assume this was Mike's way of emphasizing asymmetry
between input and output ports.

call-with-whatever-output-port returns a useful value
whose computation should be coupled with the closing
of the port.  That's just my guess as to Mike's
rationale.

> Should we include open-reader/writer-input/output-port
> (surely with a better name)

Would it take both a reader and a writer as arguments?

I have been ignoring the readers and writers, probably
because some flaws in their specification made them
appear useless to me for a long time.  (I grew tired
of arguing about that, and resolved not to look at
them again until we proofread the entire document.
Note that I have had no special responsibility for the
I/O subsystems ere now.)

Will