[R6RS] Changing the transcoding mid-stream

[dyb at cs.indiana.edu]

Thanks for the quick work, Will.  After a quick read, I have some
questions and comments, which I've included below.

Kent

--------

(buffer-mode name), (buffer-mode? obj)
  - does it really return a symbol ("returns the corresponding symbol")?
  - does (buffer-mode line) evaluate to line?
  - if answer to preceding question is no, does buffer-mode? return #t
    for valid inputs to buffer-mode or valid outputs from buffer-mode?

Is update-transcoder actually useful?

(eol-style name), (eol-style? obj)
  - "lf" is shown twice---should one occurrence be "cr"?
  - does this really return a symbol
  - does (eol-style lf) evaluate to lf
  - if answer to preceding question is no, does eol-style? return #t
    for valid inputs to eol-style or valid outputs from eol-style?
 
I assume that each of utf-8-codec, latin-1-codec, etc., are procedures

port-has-position?, port-has-set-port-position!?
  - these names are inconsistent---rename first "port-has-port-position?"
  - answer to FIXME question in both cases is yes: standard-input and
    standard-output may not support port-position

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?

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

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

We decided to eliminate close-input-port

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

We decided to eliminate close-output-port

Should we include a clear-output-port procedure?

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

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