[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: CHPROP problems



    Date: 08/17/80 06:12:35
    From: RMS at MIT-AI
    Re:   CHPROP problems

    Here are some problems with CHPROP.

    1) There is no need for functions CHAR<, CHAR=, CHAR>.
    The functions <, = and > should be used for this,
    and they should be willing to compare a character
    object with a number if those data types are different.
    Having separate functions for comparison of characters
    does not accomplish anything, because on systems which
    implement characters with fixnums, they would be the same
    as the fixnum comparison functions anyway, and on systems with
    character objects there is no difficulty with making
    the functions "<", etc., generic.
Because when I look at code and see "<", I think "Aha, fixnums are being
compared", and when I see "CHAR-<" I think "Aha, characters are being compared.
Besides, I'm not too sure what "CHAR-<" should do in an EBCDIC environment.
Maybe it should do the right thin and simulate ASCII?

    2) #/x is supposed to return a character object
    if they exist.  It sounds like people agree now
    that this should not happen, so why not fix CHPROP?
GLS?
    3) #=nnn is superfluous when there is #/nnn.
What is #/nnn besides the fixnum-represented character "" followed by nnn?
Is this a typo for #/nnn?  I do think #= is superfluous.
    4) The convention of a package called "*" seems like
    a bad idea.  I don't think the Lisp machine will adopt it.
I've argued this for years.  I think the name "*" is bad, but not the idea of a
separate package for machine dependencies.  But I'd rather see SOME standard
adopted.  If you don't like "*:", please make an counter-proposal.
    5) Right now on the Lisp machine there is one sort of
    character which can have bits and another which can
    have a font.  There is no sort which can have both.
    It might be an improvement if there were, but it might
    also be a lot of work.  This might prevent the Lisp machine
    from adopting CHPROP.
Can you determine a subset of CHPROP which you could adopt?  Modifications to
CHPROP which would aid the LISPM in adopting it?  Perhaps the notion of bits
and fonts could be collapsed into one somehow?