Programming languages should be case-sensitive, period. People can adjust to this very easily: they simply have to remember to work mostly in lower case, and to watch out for mixed-case or all-caps identifiers in existing API's.
It once seemed obvious to make languages case-insensitive. This is because lower case was not available on all computing systems and their I/O devices (keyboards, printers and display devices). Programming language implementations had to accept programs written in upper case, since only that could be displayed or printed. And for that they had to be case insensitive, because to accept upper case and be case sensitive at the same time means to reject lower case. Lower case was something programmers wanted, but could not always have. Nobody really wanted to work with programs which shouted in upper case; it was just a hardware limitation.
For a while, it was common to even do case folding in terminals. If a terminal could only display upper case, but you had to log into a computing system supporting upper and lower case, the terminal would fold the lower case to upper case. Think this was so long ago? "Like the Apple II, the Apple II Plus had no lowercase functionality." (http://en.wikipedia.org/wiki/Apple_II_Plus) When users of early Apple computers dialed into a BBS that had mixed-case content, the terminal emulator (or host) had to fold that all to upper case. Messages written in all caps were common on bulletin boards in those days. This functionality is still found in Unix-like operating systems, like the Linux kernel. For example, type the stty olcuc
at your shell prompt. The Unix tty line discipline can map lower case to upper on output, and it can map upper case to lower on input. This allows you to work in a lower case programming language, on a terminal that has no lower case.
Case insensitivity is an outdated concept from a bygone computer era that doesn't work very well in the modern world of internationalized computing. Do you extend that into other languages? How about French: do you consider È and è to be equivalent? Or Japanese? Do you consider hiragana and katakana to just be cases, so that ファイル and ふぁいる are the same identifier? Support for such folly will greatly complicate your lexical analyzer, which will have to have case equivalence maps for the entire Unicode space.
Note that mathematics is case sensitive. For instance, the upper case sigma might denote summation, whereas the lower case sigma denotes something else, like standard deviation.
This can occur in the same formula without creating any difficulties. (Will the programming language make Σ and σ equivalent?)
English orthography is sensitive. For example, many proper nouns correspond to ordinary nouns or even other parts of speech. "may" is a verb, but "May" is a month, or a woman's name. Moreover, if an acronym or abbreviation is written in lower case, it can be confusing. SAT stands for scholastic aptitude test, whereas "sat" is the past participle of "sit". Intelligent people pay attention to detail and capitalize properly.
Basicaly, any new programming language created since 1985 which is case-insensitive is FOR THOSE WHO STILL SHOUT IN E-MAILS AND POSTINGS WITHOUT A SECOND THOUGHT.
What if your language is ever used as a code-generation target to translate code in another language, and that other language is case sensitive? You will have to somehow transform all the names to capture the distinction. (So to assert that this is not a technical decision, and only matter of the emotional preferences of the target audience, is ridiculous.)
Look at the annoying problems caused by case handling in the Windows, when files are imported from another operating system. That's a technical issue. Case sensitive file systems have a problem with foreign data which case-insensitive ones do not.
Common Lisp has hit upon the ideal approach: symbol names are case sensitive, but when tokens are read, they are folded to upper case. This means that the tokens foo
, fOO
, FOO
and Foo
all denote the same symbol: the symbol whose name is stored as the character string "FOO"
. Furthermore, this behavior is only the default read table configuration. The reader can fold letters to upper case, to lower case, invert the case, or preserve it. The last two choices give rise to a case-sensitive dialect. This way, users have the maximum flexibility.
a-zA-Z
,0-9
(except at the start) and_
.