Alex Shinn <xxxxxx@gmail.com> writes:

> 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).

I don't quite understand what you mean here---it's true that you
probably can't use the underlying abstractions for text I/O, but you
certainly can perform text I/O using the facilities in SRFI 68,
building on the underlying binary I/O.  Trying to build a
multi-encoding text I/O system that's magically compatibly with what
the common platforms have (i.e. the common implementations of wchar,
.NET, Java etc.), and still functionally desirable is hard, and I have
trouble seeing the benefits.

> 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.

That distinction is really anathema to its design approach---see the
Design Rationale section.

> 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.

I don't understand what this would buy---could you elaborate?

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