[R6RS] I/O issues
mflatt at cs.utah.edu
Sun Aug 6 09:53:13 EDT 2006
At Sun, 06 Aug 2006 11:31:18 +0200, Michael Sperber wrote:
> - 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.
That makes sense to me, but I have no strong opinion.
> - 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.
I weakly favor #1, but #2 is ok with me.
> - On the transcoder-updating issue, I suggest a compromise.
> - 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?
Clamp down. A `file-options' form a library other than an R6RS library
might accept more 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.)
I worry that system-specific values might be expressible in R6RS (e.g.,
a symbol). So either restrict to what the report specifies, or somehow
constrain the acceptable additional values to things that you can old
construct with system-specific libraries.
> 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'?
I think the optional file-options argument should stay, even if the
empty set is the only value allowed in R6RS. It's a good placeholder
for system-specific options (perhaps accepted only by a system-specific
function with the same arguments as the R6RS functions).
> - 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.
Sounds good to me.
> - 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.)
I agree that it shouldn't be required.
More information about the R6RS