Email list hosting service & mailing list manager

Re: the "Unicode Background" section Thomas Lord (22 Jul 2005 19:17 UTC)
Re: the "Unicode Background" section John.Cowan (22 Jul 2005 21:56 UTC)
Re: the "Unicode Background" section Shiro Kawai (22 Jul 2005 23:54 UTC)
Re: the "Unicode Background" section Shiro Kawai (22 Jul 2005 23:32 UTC)

Re: the "Unicode Background" section Thomas Lord 22 Jul 2005 19:17 UTC

>> 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
standardization:

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

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.

-t