[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
SETF, case, etc.
- To: common-lisp at SU-AI
- Subject: SETF, case, etc.
- From: Scott E. Fahlman <Fahlman at Cmu-20c>
- Date: Wed, 25 Aug 1982 21:41:00 -0000
There must come a time when finalizing the manual takes precedence over
endless twiddling of the names of various functions. Last Saturday's
meeting was that time, in my opinion. We should now go ahead with the
names we have decided upon, and suggestions for name changes on the
basis of someone's idea of good taste or elegance should be considered
out of order. Only those changes that make some real difference
(avoiding a conflict that we failed to notice before, etc.) should be
considered at this point.
In a similar vein, we considered the issue of case-sensitivity about
nine months ago and settled on the current scheme. I don't think that
there is much to be gained by reopening the issue now. Case-sensitivity
is not something that we can leave to individual choice if code is to be
portable, and the overwhelming majority of people wanted to avoid making
Common Lisp case-sensitive. Several attempts were made to come up with
a coherent scheme to match symbols in a case-insensitive way but to type
them out in whatever case they were first seen in; all of these attempts
As it stands, intern IS case-sensitive, but the reader upper-casifies
things by default. It is easy for users to turn off the upper-case
conversion in the reader, and then they have a case-sensitive Lisp.
However, the built-in symbols are all upper-case, so these users have to
type them in that way. Code that is intended to be portable should
assume the default environment, which does not preserve case. It is
somewhat arbitrary that upper-case was chosen over lower-case as the
default, but for portability there has to be an internal default and the
tradition of past Lisps won out over the tradition of Unix.
At one point we discussed the possibility of adding a switch to print
symbols preferentially in lower-case. I can't find this in the current
manual, but it would be easy to add as an implementation-dependent
extension. This causes no problems, as long as the resulting output is
read back in through the upper-casifying reader.