[R6RS] I/O issues

[Matthew Flatt]

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.

Ok.

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

Matthew