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.
Alex Shinn <alexshinn@xxxxxxxxx> writes: > Scheme will continue to be used in a wide variety of platforms, > including embedded systems, so regardless Unicode should be > at most optional, not a requirement, just as the full numeric > tower is optional. Sure. From my perspective, the problem with the current standard is that you *cannot* implement Unicode properly. Far from requiring it, it is essentially prohibited. I fear that this SRFI is (ironically) in danger of doing the same damn thing all over again. If Scheme standardizers would just get out of the way, and allow Unicode-interested Schemes to implement Unicode correctly, I would be happy. My concern is that I want to make sure that in the next go-round of the RnRS, it is possible to write a Unicode conformant Scheme system. That's my number one bee; I'll let the rest of you all decide what the module system and macros and weird NaN things should look like. So please, just deal with the reality. There is no such thing as character-by-character case mapping. Please do not say "everyone will want one even though it's buggy, so we'll require it." Everyone will not want one. If it's not standard, then programmers will use the string-by-string procedures, and be quite happy. If you want case-mapping which follows the ASCII rules, well and good, then simply provide a locale argument to the case mapping functions (which work on *strings*) and require the existence of an ASCII locale. And then say that it is undefined what happens with non-ASCII characters if you use the ASCII locale case mapping functions. Real Unicode compliant systems can then just identify the locale- independent Unicode treatment with the "ASCII" locale, and be done with it. Thomas