CHAR-BIT

[Rob MacLachlan <RAM@CMU-CS-C.ARPA>]

I think that in the case of I/O (and thus characters) it makes a great
deal of sense to have language features which are optional.  While it
is true that no program that counts on the existance of such a feature
is totally portable, there is at least an accepted way to describe how
the program is non-portable, and a canonical implementation if the
feature is implemented.

If I sit down at a J. Random & Co. Lisp machine and type
Control-Meta-Hyper-A, there is no guarantee that the obvious character
will be sent, but if it isn't the manufacturer is guilty of criminal
bogosity.  It is true that if old J.R. didn't see fit to put the key
on his keyboard, then any program that counted on reading characters
with bits won't work too well, thus such a program is non-portable.
No program which contains any character that isn't standard-char-p is
portable, so implementors of portable programs must find some way to
factor out implementation-dependent information about characters.

Note that it is quite possible for a Common Lisp program (such as a
text editor) to do sensible things with character bits if they exist,
and ignore them if they don't.  The text editor is still portable, it
is just the key bindings which are non-portable.

I see no advantage in merging bits and code.  The fact that ASCII
merges information that would be better encoded as separate bits is
irrelevant; Common Lisp implementors have no obligation to perpetuate
ASCII bogosity.

I agree that the "font" support in Common Lisp is totally worthless.
Fortunately it is easy to ignore.  It seems that what the "font"
information is really intended to represent is a facecode, e.g.
"bold", "italic", rather than an absolute font "timesroman10b".  As
such, it would make more sense to have named character facecodes
instead of these silly numbers.  Even so, this wouldn't be terribly
useful, since having some bits hung off of every character is a pretty
poor way to represent font information.

  Rob