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.
On the one hand, I really want to be able to count on Unicode in scheme, and write portable code using it. On the other hand, I don't want the standard to specify a particular form of Unicode support that sucks, or which is not compliant to the Unicode standard itself. On the gripping hand, I don't want to lock scheme out of embedded applications with simplistic 8-bit or 7-bit character sets and no space for the big tables that Unicode requires. And on a foot, the issue of whether identifiers (symbols) are case-sensitive *DEFINITELY* affects whether code is portable, and it would be murdurously hard to specify case-insensitive symbols if we want to leave open the option of fully supporting Unicode. Maybe the right support is for the standard to remain silent on the issue of character set, while relaxing constraints that make full unicode support impossible or murderously hard, and have an adjunct or appendix that specifies a *minimal* amount of the form of optional unicode support. External representations for single-codepoint unicode characters and strings and symbols containing them, I think we can agree that everyone who intends to support unicode needs and that no particular implementation of unicode support will be unable to use. Specifying binary representation or number of codepoints per character I don't think we do need, because it overspecifys unicode support enough to force bad or unwanted choices on implementors. IOW, let's specify enough that people can write some code to the standard and so that things every unicode-supporting scheme must have in common will be portable. But not so much that implementations can't still do things in different ways and find out from experience what actually works. Bear