[R6RS] I/O issues

[Michael Sperber]

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