[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
- To: RMS at MIT-AI
- From: Robert W. Kerns <RWK at MIT-MC>
- Date: Tue ,19 Aug 80 13:33:00 EDT
- Cc: LISP-FORUM at MIT-AI
Date: 18 AUG 1980 1916-EDT
From: RMS at MIT-AI (Richard M. Stallman)
To: LISP-FORUM at MIT-AI
It seems strange to hear an objection to the use of < for comparing
characters based on asking whether it should ignore the font.
I'm sorry, that was not an objection. It was a question. It would indeed be a
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".
Fine, don't believe it was serious if you want. Here your unstated assumption
is that compatibility with the local environment is more important than
compatibility with what the code did before you transported it. I can imagive
a user complaining "but when I run it on the IBM machine, I get these funny
things in the MIDDLE of my output rather than at the end like I did before!".
I guess I'm just being an anti-IBM bigot and not considering the IBM
local environment worth being compatible with. But this is supposed to be a
character STANDARD! And ASCII is the standard character sequence.... What
do IBM people do when they have to interface with the rest of the world,
anyway? Does anybody on this list know whether they ever run programs that use
ASCII with I/O conversion, or just what they do?
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 <.
True, if the collating sequence isn't standardized. I would like very much for
it to be, but can accept that it may not be politically feasible. It's
interesting that we're arguing political positions for users who don't exist
yet. I'm not sure that these users will be IBM'er instead of being primarily
people transporting programs developed in an ASCII environment.
In general, a program using < is no more and no less transportable
than it would be using the name CHAR< instead.
This is obviously untrue if your character objects cannot be compared with the
function <. If you have a microcoded machine where < is generic and you can do
whatever you want, then fine, but if you will recall I've already covered this
point: I have not been convinced that in all implementations a character
object can be compared in the same manner as a fixnum. If you care to convince
me that it CAN, and that it SHOULD, that still levaes the argument of coding
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.
I don't know of any arguments that you can't use CHAR-CODE and use the fixnum
representation where apropriate. Certainly I haven't made such an argument.
I know I missed CWH's #/ and TYI argument before, am I missing something or
are you confused about my position?