[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: the "Unicode Background" section
>> How about: Emitting a UTF-16 encoded stream of the contents
>> of a string? Doesn't that sound like an application for
>> WRITE-CHAR? Or is that the kind of thing one shouldn't
>> be able to do in portable Scheme?
> How can you use WRITE-CHAR to implement an encoding routine?
> WRITE-CHAR is already going to have it's own encoding semantics.
> You need a binary I/O facility like WRITE-BYTE or WRITE-BINARY-UINT16
> to implement your own encoding procedures.
There are multiple options in this area and I'm describing
one that I think is worthy of experimentation before
I think it might be realistic to label ports not with
the encoding scheme they want, but with the set of
code-values they can transmit -- in other words
with their framing constraints. In other words --
a "UTF-8 port" (no such thing, really) and an "ASCII port"
(no such thing, again) are *really* just "8-bit ports".
A "UTF-16 port" is *really* just a "16-bit port".
At the same time, several of us agree that WRITE-CHAR
should accept a CHAR argument which is, in essence, a
I think an implementation should be permitted to have a
version of WRITE-CHAR which is not total for all PORT,
CHAR pairs: try to write a wide character on an 8-bit
port and that's an error, etc.