[no subject]

[GLS@MIT-AI]

CC: GLS at MIT-AI, (BUG LISPM) at MIT-AI, nil at MIT-MC

    RMS@MIT-AI 12/15/78 00:07:47
    I think that CHPROP is far too hairy.
    Distinguishing characters from numbers, just as I expected,
    is creating a need for a large number of new conversion
    functions which are not needed the old way.  I think this shows
    that the whole thing is a loss.
Thank you for bringing up a point I neglected to mention in the proposal.
There is nothing in the proposal which requires characters to be a
separate data type, and it is permissible to implement them as fixnums,
or unary lists of NILs, or whatever the implementation desires.
"Character" is merely a conceptual abstraction, like "alist",
for the purposes of the proposal.  What I have mostly done is
REMOVED the explicit dependency the LISP Machine has on the
representation in fact being fixnums.  The newly proposed functions
simply replace the byte pointers like %%KBD-CONTROL-META used with
LDB.  Also, there is an attempt to avoid a rigid requirement that
particular characters correspond to particular character codes --
after all, on an ASCII machine one will probably have the <RETURN>
character, but it will probably also be inconvenient or impossible
to represent it as 215.  As a consequence, there is a predicate
GRAPHICP, which can hide whether or not a particular implementation
was able to make thhe internal coodes for graphic characters
contiguous (e.g. 0-177).
I agree that the proposal is hairy, but I think it is hairy not so
much because of what it says, as because of what it avoids saying.
There is nothing which prevents the LISP Machine from adhering to
the proposal and also continuing to use LDB on %%KBD-CONTROL-META
-- it's just that programs which do the latter are likely not to
be able to run in various NIL implementations for that reason.