[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: the "Unicode Background" section

This page is part of the web mail archives of SRFI 75 from before July 7th, 2015. The new archives for SRFI 75 contain all messages, not just those from before July 7th, 2015.

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