From: jlg@cochiti.lanl.gov (Jim Giles)
Subject: Re: Case Sensitivity (was Re: Small Language Wanted)
Organization: Los Alamos National Laboratory
Date: Tue, 8 Sep 1992 17:53:30 GMT

In article <999@engcon.marshall.ltv.com>, rodgers@engcon.marshall.ltv.com (KMRODGERS) writes:
|> [...]
|> I hate contributing to this particular religious warfare (hence the changed
|> Subject: line), but I think that case sensitivity, WHEN PROPERLY USED, is
|> (IMHO) a Good Thing.  [...]                          These are represented
|> in handwritten or typeset form as as capital "C" followed by various upper
|> and lowercase subscripts. The case of the subscript is important!  E.g.,
|> cap "C" sub "L" is lift coefficient, while cap "C" sub "l" is rolling moment
|> coefficient -- two drastically different quantities. [...]

I, reluctantly, disagree with this.  This is using case significance as
a form of `Hungarian notation' where case has an independent semantic
meaning.  If you are arguing that the language should *enforce* such a
convention, then maybe I would agree with you (I'd have to see the whole
proposed use of case).  As it is, case has no enforced semantic meaning
and differing conventions (as well as intentional and accidental violations
of such conventions) lead to more confusion among colleagues than the
added `convenience' is worth.

In the meantime, case *INsensitivity* allows the use of case for
emphasis and for documentation.  This is also a minor convenience.
Which dominates and in what contexts is a subject for research.
But, I feel that case sensitivity is best when it has specific
meaning to the language (like: all identifiers which begin with 
uppercase are function or constructor names - and the compiler
enforces that).

|> [...]
|> If one of the goals of a computer language, especially one for scientific
|> and engineering computation, is to try to preserve as much as possible
|> and reasonable the natural notations of these fields (a claim that I have
|> heard Jim Giles make before, and one with which I agree), then I think that
|> case sensitivity is important, and this is _one_ area where C is superior to
|> Fortran. (Note the emphasis; I make no other claims in this rwar.)

Yes, and conventional mathematical and scientific notation also make use of
bold vs. normal, Roman vs. Greek, fraktur vs. times-roman (font as opposed
to alphabet), etc..  Some notations even use the front half of the alphabet
for one thing and the back half for something else (and the middle `half'
for still other uses).  Unless you can provide *all* of these, the programmer
must spell out most such distinctions explicitly anyway.  I think that in
most programming contexts, case sensitivity is undesirable.  In a symbolic
package like Macsyma or Mathematica, such notations should be supported
(including the fonts, alphabets, intensity, etc.).

In any case (alright - I noticed the pun), I think there should be some
human factors tests before anyone starts a war on the issue of case
sensitivity.  Case sensitivity should be tested, and in a variety of
programming languages and contexts - and should only be adopted in contexts
where it shows a *real* advantage.  I suspect it will usually be better
when the compiler enforces meaning on case sensitivity.

-- 
J. Giles
Xref: sparky comp.edu:1563 comp.lang.fortran:3461 comp.lang.misc:2959 comp.arch:9265 sci.math:11087 misc.education:3310