[R6RS] I/O discussion

[Michael Sperber]

To summarize a few things:

- I suggest that we consider SRFIs 79 (Primitive I/O) and 81 (Port
  I/O) for R6RS.  They're meant to be independent from the Streams
  layer (SRFIs 80 & 82), and any remaining dependence is a bug.

- As the ideas behind Primitive I/O are a bit less-established than
  behin Ports I/O, it would be possible to leave it out, and only copy
  the relevant data definitions.  We'd leave out the very last
  subsection of the specification of SRFI 81, which is about creating
  custom ports from readers and writers.  By doing that, we'd lose the
  ability to create custom ports.

- I suggest that we consider SRFI 74 (Octet-Addressed Binary Blocks)
  rather than SRFI 66 (Octet Vectors) for satisfying the "byte-vector
  requirement."  Having said that, retrofitting SRFI 66 to the I/O is
  a trivial task.  (Essentially, renaming "blob" to "u8vector.")

- I don't feel violently about using #f insteaf of the eof object, but
  do prefer #f on the grounds of convenience.

- I feel more strongly about the consistent naming and argument
  ordering in the SRFI.  Earlier revisions had something closer to
  R5RS, and it was awkward to make the various variants of
  READ-BLOB-xxx work with optional arguments.  I'd be happy to
  elaborate on the details; the "Design Rationale" contains more
  information.

- The way Port I/O deals with text encoding is a fairly substantial
  decision, and it differs from systems where text encoding is a
  mapping from binary to text.  I believe this way of handling it is
  preferable for a number of reasons, but y'all might want to
  scrutinize this aspect closely.  (I'd like this particular item on
  the agenda for next week's conference call.)

-- 
Cheers =8-} Mike
Friede, Völkerverständigung und überhaupt blabla