On 8/20/05, Michael Sperber <xxxxxx@informatik.uni-tuebingen.de> wrote:
>
> You have seen that SRFI 68 addresses all of these issues, right?

Yes, SRFI-68 can easily handle all of these issues, simply using
READ/WRITE-U8 for READ/WRITE-BYTE.  This is because SRFI-68 makes no
distinction between binary and character ports.  If we're willing to
drop that distinction, then the whole problem disappears, but we've
abandoned implementations that don't let you directly mix binary and
text operations (notably all Java implementations, and C implementations
using wchar).

Another way of looking at it is that SRFI-68 is flexible enough to allow
us to create new port types with an explicit binary vs character
distinction.  If we were to do that, then what API should we use when we
inevitably need to serialize/deserialize Scheme string objects to/from
binary ports?  A SRFI-68 approach might be to combine READ-BLOB-N with a
utility procedure

  (BLOB->STRING str [encoding])

probably implemented on top of blob-input-stream and transcoder.
This generalizes into the first category of solutions, using specific
procedures to read and write text to binary ports.

A variation on this approach is simply to unify those procedures with
the standard character port procedures.  In other words, READ/WRITE-CHAR
would be guaranteed to work on any port, including binary-ports, and in
some implementations this would involve a check to see if the port is
binary and if so use a separate path from the native underlying port
operation.  This is why SISC is able to provide READ/WRITE-CHAR for its
binary ports and thus pass the integer part of the test suite - when a
character procedure is called on a binary port it just returns a single
octet value (as though the port were Latin-1), instead of signalling an
error as the underlying Java library would.  UTF-8 could just as easily
be used.  Using this strategy we would still not guarantee binary
operations on a character port - if you need to mix I/O, use a binary
port.  It's a little more work for the Java implementations, but a simpler API.

--
Alex