Case-sensitivity goals, policy and implementation

It is true that one can control, inconveniently,
the treatment of upper and lower case characters in ANSI CL.
(it was even less convenient before the "reader" specification
was enhanced.)

The inconvenience is caused largely by the rule that
...by default..., ANSI CL is case insensitive. This encourages
people to write program files in which case must be
mapped. That is, default in an ANSI CL will allow any
of these spellings to be equivalent: SIN, sin, Sin, SIn.
They all become SIN . Some people seem to use this.

Now you can as you point out, we could change the way lisp
reads, but this is like saying, if you don't like the seats
in your car, you can always replace them.  You don't do
it casually.    Instead most people, if forced to find
an incremental solution, simply can construct mixed case identifiers
by certain quoting mechanisms.  In particular we can construct
symbol names with lower or mixed case this way:
sIn  could be written  |sIn|.  It would be routinely
displayed that way. |Personally| | |do| |not| |like| |this| |convention.|

I do change this convention (e.g. buy a car with different
seats:)  )  by using a non-ANSI "modern"
Common Lisp from Franz Inc.  Except when I load a pre 5.9 Maxima
into it, when I must use ANSI default, this lisp works without
any problems.
   I suppose someone who randomly hits the shift key while
typing might have a different view.

RJF



Andreas Eder wrote:

> Richard Fateman writes:
>  > The controversy and various approaches
>  > has been pounded to death by the people at
>  > Franz Inc, some of whom feel strongly that the ANSI
>  > CL decision was wrong (case insensitive), but
>  > that it must be accomodated somehow.
> 
> 'm not an expert on Common Lisp and far from a language lawyer, but I
> think that ANSI CL is +not+ case insensitive, but is in fact case
> +sensitive+. It is just that the default for the reader is to upcase
> input, but you can change this either programmatically or ad hoc, just
> as you please.
> 
> Andreas
>