This page is part of the web mail archives of SRFI 50 from before July 7th, 2015. The new archives for SRFI 50 contain all messages, not just those from before July 7th, 2015.
> From: Ken Dickey <Ken.Dickey@xxxxxxxxxxxxxx> > I am happy to write programs in which identifiers are limited to those > characters supported today in R5RS. It is, as near as I can tell, not entirely clear what those characters are. > But I would like to be able to manipulate Unicode strings > natively -- even if as a separate datatype than current strings > (I assume conversion/mapping functions). I am satisfied if > STRING->SYMBOL signals an error if non-ascii characters are > used. My proposals for R6RS promises nothing more than that. Slightly less, actually. > So in the "weak" case, I would support a new, UNICODE-STRING > datatype SRFI and reasonable set of operations which has well > specified interactions with strings as currently defined. > I see no reason that this could not be done as a library with > little impact on R6RS and no need to codify a such a standard > prior to a wide experience of its consequences. > [Comments? I Know you have comments! 8^] The weak proposal is fine (and, indeed, "weak" :-) However, I think that revisions to the standard are still needed to: clarify the requirements for the portable character set; clarify whether there are required casemappings and, if so, what they are; slightly weaken the required case-oriented procedures in such a way as to permit sane Unicode-supporting Schemes in which Unicode characters and strings are _not_ disjoint from CHAR? and STRING? In addition, while we've got the engine pulled, I think we can/ought to throw some strong _recomendations_ into R6RS to discourage or at least flag as exceptional some of the really ridiculous readings of the standard that would remain legal. -t