Thomas Lord scripsit: > I appreciate that: almost all popular criticisms of Unicode as a > universal character system are wrong. Unicode is designed extremely, > almost painfully, well. The correct architecture it uses is then well > appointed with the actual list of abstract characters, arrived at by an > impossibly difficult political process. Like Scheme, Unicode is a gem.
Boy howdy, that's the *last* comparison I'd ever make. Unicode is at best a diamond in the rough: the result of, as you say, an impossibly difficult political process that embedded 18 years of compromise after compromise, blunder after blunder. It is a history comprising a steady tightening of constraints, a steady raising of several different bars, and there are people who legitimately fear that the pressure to freeze it absolutely will become effective before the work is finished. There are a lot of scripts that we know just how to encode, but a huge amount of practical work has to be done, and there simply is no money, so the few people who are actually qualified end up working 18 hours a day so that they can both make a living and get the job done. Much like democracy (and let me take this moment to add that while I do believe in the right of the majority to have its way, I also believe in the rights of minorites, particularly in this context the right to be heard), Unicode is the Worst Possible Thing, except for all the alternatives. > 1) Should the standard allow a conforming implementation to support only > a smaller character set in source texts? (I say "yes" for pragmatic > reasons - I don't need all of Unicode or all the Scheme libraries in > the world for a tiny embedded system, for example.) That could be achieved by (a) allowing implementations to require that all non-ASCII characters in identifiers be escaped, and (b) allowing implementations to accept invalid identifiers, provided they cannot be mistaken for numbers, strings, or whatever. (This is already true in many R5RS implementations.) > 2) Should the standard allow a conforming implementation to support a > larger character set than Unicode? (I say "yes" for experience-based > reasons. For example, you'll pry my bucky-bits from my cold dead > hands.) > > 3) Should the standard allow a conforming implementation to to treat > a class of objects such as Unicode compound characters (an infinite > character set)? (I am persuaded by what Dillenger has sketched - > "yes" again.) These considerations could be bypassed by eliminating characters as primitives. > I have a sense that you want to use a standard to "force" implementers > not to blow off Unicode support. I think that's philosophically and > politically wrong. No one is forced to comply with standards, nor do standards dictate the behavior of implementations that don't claim conformance to them. -- Mos Eisley spaceport. You will never John Cowan see a more wretched hive of scum and [email protected] villainy --unless you watch the http://www.ccil.org/~cowan Jerry Springer Show. --georgettesworld.com _______________________________________________ r6rs-discuss mailing list [email protected] http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
