Bits for input, fonts for output

[Rem@IMSSS]

I agree with Fahlman's message, that neither keystrokes nor fonts & presentation
is what we normally want internally in strings. I'd like to go further.
For the most part, what you want in strings is similar to what you want
in PNAMEs. Do you really want the name of some function to be [First character
plain vanilla "F", second character plain vanilla "O", third character
HYPER-META-"O"?] so that you can't access that function without somehow
getting HYPER-META-"O" actually into LISP rather than escaping to some
user-interface side-effect such as inserting ten blank lines in the
current window? 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.

Re 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 may be that we can't adapt CL to handle kanji
in the right way (portably) without adding gross overhead to the ASCII-only
implementations. It may simply not be reasonable to extend CL to handle
kanji in a portable way, thus we may relegate kanji to an extension
rather than to portable CLtL. Anybody have any workable solutions??
Or should we punt on kanji this year?
-------