[no subject]

[RMS at MIT-AI (Richard M. Stallman)]

It seems strange to hear an objection to the use of < for comparing
characters based on asking whether it should ignore the font.
When I suggest that < be used instead of CHAR<, I mean exactly that.
CHPROP says clearly that CHAR< doesn't ignore the font, or any
other part of the character.  CHAR-LESSP is used for that.

I can't believe the suggestion that CHAR< ought to use the ASCII
collating sequence on an EBCDIC machine is serious either.  Clearly
anyone writing a Lisp for such a machine will make CHAR< use the
machine's own collating sequence: which is to say, he will make it be
the same as comparing the fixnum equivalents of the characters,
because that is what the machine's own collating sequence is.  If you
tried to tell him to make it do ASCII comparisons, he'd probably say
"but on our system we don't use the ASCII collating sequence and I
want comparing characters in Lisp to be compatible with comparing them
in all the other languages on our system".

What this implies is that a transportable program shouldn't
make assumptions about the order of the collating sequence,
regardless of whether the function is called CHAR< or <.
For that matter, it must not make any assumptions about the
collating sequence in use with CHAR-LESSP.  Please don't
make the claim that this says anything about the suitability
of "<" for transportable programs unless you are willing to
accept the conclusion for CHAR< and CHAR-LESSP as well.
In general, a program using < is no more and no less transportable
than it would be using the name CHAR< instead.

By the same token, making use of the fact that a character has an
equivalent as a fixnum doesn't imply nontransportability.  It might be
used to do something nontransportable, but that is not all it is good
for.  For example, it might be used as an array index, or be stored in
a numeric array.  It might be used to generate a hash code to index an
array, if it has too many bits to use as an index as it stands.  These
things can be done without depending on the particular value of any
character(s).  Only arithmetic causes a problem, and then the same
problem can occur operating on just the code part of the character.
If it is bad to allow the entire character to be turned
into a fixnum, it is just as bad to allow CHAR-CODE.

It is true that someone might turn a character into a fixnum and then
use LDB to extract the font.  That would be a mistake, if there is a
convenient function for doing just that.  Similarly, it is a mistake
to use PROG and GO to do something that is a trivial COND; but that is
no reason not to have PROG and GO.

Given that a character either IS a fixnum, or is a fixnum with a funny
data type field, there should be no obstacle in the way of making use
of this fact.