[R6RS] Changing the transcoding mid-stream
William D Clinger
will at ccs.neu.edu
Wed Aug 23 07:42:26 EDT 2006
> (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?
> 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
> - does this really return a symbol
Yes. I'll simplify the wording.
> - does (eol-style lf) evaluate to lf
> 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
Okay. I'll remove those questions.
> Should we consider:
> (call-with-ports proc port ...)
> (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.
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
> 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
> 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?
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
> 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.)
More information about the R6RS