[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: More case
- Subject: Re: More case
- From: Earl A. Killian <EAK at MIT-MC>
- Date: Sun ,1 Feb 81 18:21:00 EDT
I believe that InterLisp originally uppercased things on input,
and then stopped. This had two effects: 1) you could then use
mixed case in your programs (and many users now do, using case
changes instead of "-" or "_" to separate words in a symbol, e.g.
"NumberOfFrobs"), and 2) you had to start typing predefined
symbol names in uppercase (though since DWIM will correct case
errors without asking, this is sort of like EMACS's handling of
case: remember it on definition and match any subsequent case
usage on input).
The InterLisp approach (except for the DWIM hack) can be done in
MACLISP (and I believe the LISPM) with a simple SSTATUS.
Unfortunately, this tends to be fairly ugly, in my opinion,
because the predefined symbols are all uppercase, though there
are those that like it that way. I also find the current MacLisp
practice ugly, though at least I see it only when in LISP system,
and not in the editor. (Uppercase letters YELL at you instead of
speaking in a normal voice; that's why saying "this does NOT
frob" works. I don't like being yelled at by my computer all the
time.) My preference would be to have predefined symbols be
lowercase, and have the reader lowercase on input, instead of
uppercase. Not very much code would break that way. Users that
wanted case sensitivity could then do the simple SSTATUS, and
type in their stuff mostly in lowercase, using uppercase where
appropriate.
The only other way to win, seems to be to hack it on output as
RMS suggests. I'm not sure how I feel about that yet. I presume
that symbols FOO and |foo| would not both print as "foo", but as
"foo" and "|foo|"? If that's the case then there is no
ambiguity. Presumably |z| is too ugly for RJF's purposes, so
this doesn't really provide him a good way to optionally have
case sensitivity.