[R6RS] I/O issues
sperber at informatik.uni-tuebingen.de
Sun Aug 6 05:31:18 EDT 2006
I've checked in revisions for the I/O SRFIs. These mostly represent
my attempt to go through them an identify open issues. It would be
nice if we could make some progress on resolving them in the next
conference. Here's a list:
- The syntax for `transcoder' and `update-transcoder' is the way it is
so that extensions can be added. Note the language saying that any
clause not covered by the spec is ignored, rather than causing an
exception to be raised. Given that we're raising exceptions almost
everwhere else, maybe we should move to a procedural interface.
- The eol-style issue is more complicated: Unicode, in order to
"resolve" the CR/LF mess, has an additional scalar value U+2028
meant to replace the old conventions eventually. There are several
ways to deal with this:
1. Ignore the issue.
2. Make `get-line' accept U+2028 in addition to LF.
3. Introduce another eol-style called "ls". This will translate
CR/LF and LF to U+2028 on output. On input, it's less
clear---supposedly no transcoding happens. For the lf and crlf
styles, these all get transcoded to U+2028. This means that
`get-line' (or whatever it ends being called) would accept U+2028
as a line delimiter exclusively.
This would probably be closest to the intentions of the Unicode
committee, but, I think, goes too far against common expectations
that LF delimits a line. Think of (put-string "\n")---we don't
even have an escape for U+2028, and Latin-1 ... We might introduce
a replacement for `newline' (called `put-ls' or something), but
it's a mess.
I'm personally in favor of #2.
- On the transcoder-updating issue, I suggest a compromise. Add a
"settable" field to the transcoder (defaults to #f) that says
whether the port opened with the transcoder will support changing it
mid-stream. Supply a `set-output-port-transcoder!' procedure that
changes the transcoder if the existing transcoder is settable.
(Instead of making the transcoder itself mutable, as suggested by
Will.) This has the advantage that we can replace a settable
transformer by a non-settable one, letting the implementation choose
an appropriate buffering strategy, and forcing no buffering only
when a settable transcoder is replaced by another settable one.
- The syntax for `file-options' was originally meant to be extensible
by implementation-specific flags. Should we keep it that way or
clamp down on the available flags?
- If we restrict the construction of transcoders and file options to
what the report specifies, do we leave some room for procedures to
accept values created by system-specific facilities outside of R6RS?
(This is already the case for file names.) Note that, if we do
restrict file options to what's specified, they make no sense for
readers and input ports. In that case, should we still provide for
an optional file-options argument with, say, `open-file-input-port'?
- In what library do the condition types live? As they're shared
between primitive I/O and port I/O, I suggest a separate library.
- The &i/o-reader/writer and &i/o-port condition types provide a
reader, writer or port with a condition. To what extent should we
require the various operations to include this in a condition?
Specifically, if, say, the read! procedure passed to
`make-simple-reader', raises an exception, should `reader-read!'
catch it and augment it with a &i/o-reader/writer condition? (I'm
thinking not---these condition types are purely informational, but
in interactive operation and debugging.)
Cheers =8-} Mike
Friede, Völkerverständigung und überhaupt blabla
More information about the R6RS