Issue: READ-CASE-SENSITIVITY (Version 1)

[Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>]

I appreciate your good intentions in writing this proposal, however I
do not agree that the proposal satisfies its stated goals without
intruding.

I will begin by making a few remarks about case-sensitivity, how (by
my recollection) we came to the state that we're in, and why I don't
think the state is as bad as portrayed. Then I'll move to criticisms
of the proposal itself, and finally to suggestions about alternate
ways to proceed if you want to pursue this further.

EQ symbols cannot print differently in different places without help
 from some global context switch.  *PRINT-CASE* is such a switch.

If case is -ever- to be signficant, case must be preserved internally.
That is, to even accomodate the idea that |CAR| and |car| might denote
different symbols, it is necessary to define that the internal
representation distinguishes |CAR| from |car|.  CLtL indicates that this
is true.

If case is significant internally, then every symbol must have a
well-defined internal casing in order to be found. That is, since by the
previous paragraph |CAR| is distinct from |car|, we must say whether CAR
denotes the former or the latter.

An arbitrary choice must be made between whether CAR maps to |CAR| or
|car|. Otherwise, when you do (DEFUN CAR ...), you have to create
symbols |CAR|, |CAr|, |CaR|, |Car|, |cAR|, |cAr|, |caR|, and |car| and
put the definition in all of them in order to not cause confusion when
you later do (Car x).

Some case had to be chosen. The arbitrary choice made was uppercase.
Personally I think this was the right choice, but I recognize that others
would have preferred lower. In any case, the operative word is "arbitrary".
Any change at this point would be de-stabilizing to no good end.
If lowercase had been chosen, we might be listening to uppercase enthusiasts
complain that lowercase looks dumb. In the end, that form of argument has
to be discounted as useless because it cannot lead to a resolution that will
be happy for all.

What should be the issue is: what options and tools can we provide that
allow as wide a variety of user programming styles as possible without
breaking the ability to load code written by different programmers into
the same environment.

*PRINT-CASE* was very carefully chosen after a -huge- amount of
discussion to permit flexibility -without- affecting the semantic
correctness of code. That is, if you set *PRINT-CASE* globally, you
don't interfere with the correct operation of libraries that others
have written, regardless of whether their original program or
runtime data is uppercase, lowercase, or mixed case. 

On the other hand, your proposed *READ-CASE* does not have this property.
You could not set it reliably because you would never know when some
macro or some data-manipulating utility would call something like
READ-FROM-STRING behind your back and get screwed because you'd changed
the semantics of that operation. It would therefore not contribute to
modularity.

In spite of what I would characterize as superficial criticisms from
people about Common Lisp and/or *PRINT-CASE*, I think that in fact we
have made a very reasonable compromise between flexible style and the
need for programs to snap together reliably.  Your *READ-CASE* proposal
is incomplete because the test case does not show the calling of a
built-in function. Leaving aside issues of what would out and out break
if you set *READ-CASE* to :DOWNCASE, you'd end up having to write 
 (CAR Zebra)
rather than being able to write (as you already can)
 (Car Zebra)
for example. I personally think this is ugly, and I think many novices
would mis-read the documentation and believe that if they set this
variable, they could use lowercase ... only to find that they got 
confusing undefined-function warnings which they do not currently get.

A more technically reasonable alternate solution might be to extend
*PRINT-CASE* to take a sort of alist as a value. Eg, consider:
 ((ZEBRA . "Zebra") :UPCASE)
so that you could override the casification of some words on a 
case-by-case basis and then fall through to a general rule. However,
my guess is that while this is technically workable, it would be
too tedious in practice (and perhaps to computationally expensive
for the printer if the alist got very long).

I am also ammenable to the idea of creating a portable way to modify
the readtable to turn off case translation. We should strongly discourage
people from doing this to the default readtable because it would have an
invasive effect on programs they didn't control and perhaps didn't even
realize existed, but the idea of constructing private readtables that
don't case-translate for whatever purposes seems highly reasonable.
This would address points #1 and #2 in your rationale, which I agree is
an excellent point. [Btw, that sort of thing should be in the problem
description.]

Point #3 of the Rationale is, as I've discussed, not a problem but a
feature. It's perhaps not as strongly motivated in the writeup as it
might be, but I stand by it strongly.

Regarding your final `Rationale' statement: ``We live in a mixed-case
world, and it should be possible to make use of case distinctions in
Common Lisp.'' I agree only to the extent that it does not harm 
program modularity. My two counter-suggestions above are intended to
help clarify the point that I am not objecting to your problem 
description as unreasonable but rather to your solution as overly naive.

Also, following directly from my above remarks, your Cost of Users is
drastically understated. The feature is not compatible since the very
presence of *READ-CASE* would mean that programs would not snap together
reliably if this variable were ever set. In practice, this would mean
that any call to READ would have to be surrounded by a binding of
*READ-CASE* just in case.  Rather than your whimsy suggesting of
READ-PRESERVING-CASE, you'd end up with a desperate need for
READ-IGNORING-CASE all over the place just in case you ever loaded into
a hostile environment where READ did not behave as expected.

Regarding your statement of Aesthetics, I certainly don't think the
addition of another switch would be a big deal if it would buy something
useful in a non-invasive way.

One parting remark, I think the proposal name LIKE-PRINT-CASE is confusing.
I would have expected that to mean `things typed in get downcased.' Only
pragmatics would tell me this is ludicrous. Since I sometimes suspect
that some people don't really read much if any of these writeups and that
these proposal names end up having undue weight, I'd prefer something else.

Ok, two parting remarks, :DOWNCASE should really be :DONT-UPCASE since it
doesn't really distinguish :CAPITALIZE from :DOWNCASE.

Anyway, as it stands, Pitman is steadfastly opposed to LIKE-PRINT-CASE
for the stated reasons.