From the draft:
 > Some Schemes may wish to distinguish between binary and non-binary
 > ports as in Common-Lisp. As these can be layered on top of the
 > current ports this may better be relegated to a separate SRFI.

Huh?  This is backwards.  The current ports are character ports.
As such they are layered on top of byte ports.  I.e. non-binary
ports are layered on top of binary ports.

Remember that one character may be many bytes.

You have to specify when the port is *opened* whether it is a
binary or character.  The alternative is for read-byte/write-byte
to peek into the implementation of a character port, and operate
on the underlying byte port.  This is losing:
(a) It complicates synchronizing (buffering) between the character
stream and the byte stream.
(b) Some implementations of character streams may buffer a chuck
of bytes.  If some bytes in the file cannot be mapped to characters
in the current character encoding, an exception may be signalled.
(c) In some environments you cannot get at the underlying byte
stream from a character stream.  This includes Java.  A Scheme
implementation could do its own implementation of character streams
such that you could get at the underlying byte stream, but then
the read functions would only work on character streams created
using Scheme run-time routines, which complicates both implementation
and interoperability.

It makes no sense to mix character and binary I/O on the same port.
Anyone who tries it is in a state of sin.

Kawa does treat binary ports as character ports with a special
character encoding of "binary".  Character ports may of course
have different encodings (UTF-8, Latin-1, JIS, ...) which defines
how bytes are mapped to characters and vice versa.  This encoding
must be specified when the port is opened.  The "binary" encoding
is basically char->integer and integer->char.  I.e.
reading a byte I returns (integer->char I).  The advantage
of this trick is that a lot of existing Scheme code that assumes
that characters are the same as bytes can continue to work.
That essentially forces the character encoding to Latin-1 with
Unix line terminators.

The alternative is to prehibit the existing character port functions
(read, display, read-char, etc) on binary streams.  That is probably
cleaner and safer.
--
	--Per Bothner
xxxxxx@bothner.com   http://per.bothner.com/