On Saturday 24 January 2004 12:35 am, Tom Lord wrote:
>     > 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.

They are restrictive and well specified.

From R^5RS [7.1.1 Lexical structure]:

<identifier> ---> <initial> <subsequent>* | <peculiar identifier>

<initial> ---> <letter> | <special initial>

<letter> ---> a | b | c | ... | z

<special initial> ---> ! | $ | % | & | * | / | :
                     | < | = | > | ? | ^ | _ | ~

<subsequent> ---> <initial> | <digit> | <special subsequent>

<digit> ---> 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9

<special subsequent> ---> + | - | . | @

<peculiar identifier> ---> + | - | ...

>
> 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?

Given the hair with Unicode (e.g. you have to know a locale to know how to
sort strings), I still prefer uni-char and uni-string (or perhaps
uni-char-vector] types.   I would like to be able to view uni-char and
uni-string literals in ascii (i.e. it should be part of the specification
that an portable (ASCII) display representation be used where extended
character sets are not natively supported).

In particular there are language scripting systems such as Devanagari, used by
about a billion people, which require complex ligature layout algorithms just
to be displayed properly.  I would recommend that specification deal only
with individual and arrayed characters and not with the scripting systems
which map characters to their visual display.

> 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.

Given that R5RS as written has constraints that do not allow much of the
complexity that is being discussed with Unicode, an alternate reading is that
implementations which break such constraints are non-conforming.

By all means, clean up any silliness. [I have not seen such, but I do not have
time to read the volume of email generated by this list, so I had best just
shut up now].

Cheers,
-KenD

PS: I would expect that the included code which implements R5RS READ (less
number recognition, but I can send that file as well) still should behave as
expected under whatever new standard emerges.