[R6RS] I/O design

[Michael Sperber]

I'll try to clarify what the distinguishing characteristic of the
original SRFI-81-based design was:

SRFI 81 views textual I/O as essentially a different way of performing
binary I/O:

For input ports, it's just a different way to convert the bytes into
data (octets and bytes objects for binary I/O, characters and strings
for textual I/O), and for output ports, it's just a different way to
convert data into bytes.  ("Binary I/O" in the context of SRFI 81
means "I/O to and from octets and byte objects".)

The correspondence between text and binary data is explained by a
variant of UTF-8 (no EOL conversion, invalid encodings are replaced by
an error character).  Thus, every byte sequence has an interpretation
as text and vice versa.  (It's not an invertible mapping, but that
doesn't seem to matter much.)  Anyhow, at this level, interleaving
textual and binary I/O is no problem at all.  For un-transcoded ports,
you also don't run into trouble with get-position and set-position! 
operations.

Transcoders map between byte sequences and byte sequences.  This makes
them composable (the reference implementation had separate orthogonal
translations for the text transcoding and EOL handling, and just
composed them appropriately; the same would have been possible for
error handling).  As a consequence, a transcoder defining a, say,
UTF-16 codec would convert between UTF-16 and UTF-8, rather than
between UTF-16 and text.  (SRFI 80 also gave you the means for
defining your own arbitrary translations, and these weren't restricted
to text codecs.)

As soon as you transcode a port, mapping between port positions of the
original and the transcoded port becomes impossible in general.
Moreover, getting back to the un-transcoded port from the transcoded
one is difficult in the presence of buffering because of this, which
is why `transcode-port!' is a one-way-only operation.  This "one-shot"
aspect of the mechanics of transcoding re-appears in Will's proposal,
in a slightly different form.

As far as the operations are concerned, SRFI 81 gives you (I think)
strictly more than Will's proposal: As soon as you've transcoded,
Will's proposal prohibits binary I/O entirely, whereas SRFI 81 gives
you transcoded binary data.  So, as long as you don't do binary after
transcoding, you shouldn't feel much of a difference pragmatically.

As a note on Will's proposal: I'm unclear why the rationale for
avoiding layering in the case of Primitive I/O doesn't also apply to
layering textual ports on top of binary ones.

PS: Note that the I/O proposal of the current draft gives you
interleaved binary and textual I/O where the binary I/O remains
un-transcoded.  I've also played around with variants of that for
Scheme 48, but have come to prefer the solution outlined in SRFI 81.

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