[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Parsing Scheme [was Re: strings draft]
> 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
My proposals for R6RS promises nothing more than that. Slightly less,
> 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.