John L. Ries wrote:
On Sun, 12 Sep 2004, Adriaan van Os wrote:
Frank Heckenbach wrote:
Which case-sensitive one? It's Pascal code, and Pacal is case-insensitive.
That may have been a wise design decision in the 1970's when programs were written on punch forms and then typed out by card punch operators. Anno 2004, it is an anachronism. I agree with Waldek that humans are case-sensitive - at least I am.
Regards,
Adriaan van Os
OK. Time to shoot off my keyboard...
IMHO, case-sensitivity is the single worst feature of both UNIX and C. In human language, capitalization is a grammatical construct which carries little or no semantic meaning (ie. the meaning of a word is almost never dependent on how it is capitalized). People will thus expect computer languages to work the same way. Given that this is the case, case-sensitive file systems and programming languages are guaranteed to confuse the unwary (and sometimes even the wary) without providing any discernable benefits other than a slightly simpler parser. It is one of the many reasons why C code is much more difficult to debug than Pascal or Fortran code.
Mind you, having a file system or programming language remember the capitalization of a word for display purposes can be useful for readibility, but to me, it makes no sense at all to permit two variable or file names with identical spellings, but different capitalizations.
Back to work...
A little history: Capitals and Italics began life as separate type styles. In the old (old) days of printing, there were no punctuation marks and writing looked like
thisisasentenceiexpectyoutoread
As type styles evolved, punctuation and spaces between words became customary. In addition, both capitalization and italics became seen as simply alternate styles of the same type set. Another "minor style difference" was bold; an example of a style difference that didn't become a style of each typeface is serifs.
The question of what to use these differences for was decided by common use. Bold and italic became emphasis characters. Capitalization is a stranger case. Because it started as an alternate typeface, whole documents were written in it. However it became considered as a hard to read typeface, and became depreciated for use in more than a character or two. Hence, it fell into todays common conventions, as a sentence start character (essentially a punctuation aid), or the start of proper names. It also became common to use all caps for signs, but this itself is fairly controversial (among typographers). Headlines use it, but freeway signs don't.
When telegraphs evolved to teletypes, circa 1930, only one set of characters was deemed more economical. All caps was the most common set of characters, probably because it was seen as a sign (or headline) font. This carried over into computers for obvious reasons. When computer terminals that used both upper and lower case evolved, upper case was still misused as an emphasis character, probably because it was the only other font on the keyboard. To this day, emphasis characters remain second class citizens. There is no bold or italic key on a computer keyboard. There is a shift key.
Having "computers work differently than people" is and old controversy. Infix vs. Polish notation in expressions, the ":=" operator vs. "=" for assignment, array indexes starting with "1" and not "0", these were all about making sure the computer notations followed common usages outside of computers, irregardless of the "right/wrong" nature of what are, after all, fairly arbitrary conventions.
In as far as case is concerned with Pascal, Pascal was clearly designed with pains to use human conventions, even if arguably inefficient (the "1" based convention of Pascal sometimes generates extra bounds adjustment code). C was not. GPC clearly has as one of its design goals the integration of Pascal and C (not considering if that is a good or bad idea at the moment).
Therefore, unfortunately, the proper behavior of GPC is clear. It must warn against Pascal types that are exported, which rely on case insensitivity, i.e., exporting both MyVar and myvar. These names will clearly cause trouble between the two languages.