[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: finalize or withdraw?
Alex Shinn <alexshinn@xxxxxxxxx> writes:
> On 8/20/05, Michael Sperber <sperber@xxxxxxxxxxxxxxxxxxxxxxxxxxx> 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
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