[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: CHPROP problems
- To: RMS at MIT-AI
- Subject: Re: CHPROP problems
- From: Robert W. Kerns <RWK at MIT-MC>
- Date: Sun ,17 Aug 80 23:10:00 EDT
- Cc: LISP-FORUM at MIT-MC
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?
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?