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