> From: Ken Dickey <xxxxxx@allvantage.com>

    > 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