Kanji, Foreign characters

[nttlab!umemura@su-shasta.arpa (Kyoji UMEMURA)]

>>Do you really want the name of some function to be
>>"FOO" in the Bodini font, so you have in that font or you can't access
>>that function? True there are some plain vanilla characters you hardly
>>ever want in the PNAME of an identifier/symbol, but in general you should
>>be able to do INTERN or STRING2ID or whatever on an arbitrary string of
>>whatever you consider legal characters. Any information that isn't
>>reasonable for coercing into a PNAME shouldn't be considered a normal part
>>of strings either. Use extended strings (fat strings or whatever) for
>>all that other cruft.

>The Japanese person who wants to include kanji etc. in PNAMEs of symbols
>(names of functions and variables mostly), I agree. Get rid of fonts
>and bit attributes in PNAMEs, but allow an implementation to have fat
>characters in vanilla strings and PNAMEs. -- One problem, how do you
>exchange programs between ASCII-only implementations and 
>KANJI implementations?
>I don't know the answer.

  It is necessary to convert a fat string to an unique SIMPLE-STRING and
the simple string can be converted to the original fat string. It is similar
case CHAR-INT & INT-CHAR. The character code may be implementation dependent
(for example EBCDIC or ASCII). However, the existence of "one to one mapping"
between two data types has a very important meaning for programmer. The
converting method between a fat string and a simple string might be
implementation dependent. However CLtL should define the function names for
the conversion.

  If these functions are defined, the converted simple string can be used
in "foreigner"'s PNAME. The "foreigner's" documentation string can be stored
in converted simple one without any extra space. A part from foreign
characters, a documentation with fonts can be realized with the same
way. It will be useful for all CL users.

  These functions might be identity function in some Japanese implementations,
where STANDARD-CHAR includes all KANJI character. Another implementation might
use escape character for converting a fat string. Another implementation use 
special codes for saving space. Whatever conversion might be, a portable
code can be developed if the "one to one mapping" is defined clearly.
--- kyoji Umemura