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

Desensitizing case-sensitivity



As SEF says, it looks like the issue is *nearly* unanimous now, so there's
not much need for more discussion.  Unfortunately, due to some kind of
mailer lossage, my note on the subject, dated Sep 3, didn't get delivered;
I'm reproducing it below, primarily for the benefit of comments which 
may tend to make the "*nearly* unanimous" choice more palatable.
[p.s. these points won't be covered in the final exam for the CommonLisp
 reading course, but you may get extra credit for perusing them]

Date: Fri, 03 Sep 1982 20:00:00 -0000
From: JonL at PARC-MAXC
Subject: Case sensitivity of CommonLisp -- Second thoughts on the modest
 proposal
To: Kim.Jkf@Berkeley
cc: CommonLisp@su-ai,franz-friends@Berkeley
In-Reply-to: Jkf's msg of 29-Aug-82 22:02:05-PDT [and subsequent msgs of
 others]

This issue is dragging on entirely too long, so I promise this to be my last
entry into mire.

It seems that two independent issues are brought up here, and confusion
between the two has led to more flaming than necessary:
  1) What is the default action of the reader -- InterLisp style (case sensitive)
     PDP10 MacLisp style (uppercasify non-escapeds), or Unix style
     (lowercasify non-escapeds). 
  2) What shall be the name of the standard "white pages" functions.  All
     upper case or all lower case.
Certainly I hope no one is still trying to throw out the reader escape
conventions, by which *any* default choice can be ignored (i.e., backslash
and vertical bar).  

I'm a little appalled that so few have seen the advantage of a case-sensitive
reader with a shift-lockable keyboard.  Having adjusted to InterLisp on the
XEROX keyboard I can honestly say that I prefer it slightly to the case-
insensitive MIT world that I came from.  In fact, oodles of InterLisp users 
seem to have no trouble typing the uppercase names of standard functions 
(and thereby being coaxed into using mostly uppercase for their own symbols)
in this case-sensitive system.

Some keyboards have a shift-lock key that is less usable than desirable;
even if we should adopt a case-sensitive reader (I think unlikely?) would
it be in any way desireable to decide such an important issue on the basis
of some keyboard manufacturer's goof?

Thus I'd prefer to bypass Masinter's "modest" proposal, agreeing with Moon
that it is a "radical" proposal, not because of wanting the default reader to be
case-sensitive (note however, that Moon strongly objects to this) but because 
of the gross switch of *historic* function names from "CAR" to "car" and so on. 
This, I'm sure, almost anyone in the non-Franz MacLisp/Lispm community
would find totally unacceptable.   I refer again to the mistake made in Multics
MacLisp, which adopted this notion, and the years of pain we had 
accommodating to it (see also Moon's commentary on this point.) 

In fact, Larry's later message of 31-Aug-82 18:51:03 PDT (Tuesday)  makes
it abundantly clear that the current (non-radical) mode of operation is 
a winner.  As he says:
   I have on more than one occasion taken someone else's Interlisp program 
   and (without very much pain) converted all of the MixedCaseIdentifiers 
   to ALLUPPERCASE before including it in the Interlisp system (in which,
   although mixed case is allowed, all standard functions are uppercase to avoid
   confusion.)
   This has been acceptable. That is: "it tells the case-sensitive folks that 
   it is OK for them to use mixed-case with sensitivity, but that if they do so, 
   their package will have to be converted before it will be accepted into
   CommonLisp."
Wouldn't there be less confusion if we adopted this as a modest proposal, namely
that "...all standard functions are uppercase to avoid confusion."

Incidentally, I view the style of the CL manual as more GLS's personal
preference about readability of manuals, rather than any inherent property
from which we can deduce an answer to the question in front of us.   I
myself would prefer UPPERCASE for white-pages function names for exactly 
the same reason, readability -- but this is an extremely small point and I'll be
happy with whatever GLS does about it.