Previous mail
Next mail
Unformatted/full headers
Overview 10 days
Subject
Date
Thread
Author
From: John L. Ries
Subject: Upper/lower case in identifiers
Date: 13 Sep 2004, 18:45:59
I agree with everything you said in your reply. What I take issue with is the notion that Pascal's case insensivity is an anachronism or in any way unfortunate; I regard it as a asset. Furthermore, I have yet to see a rational argument in favor of case sensitivity in programming languages. Given, however, the widespread use of C and other case sensitive languages (I use them too), it is useful to have case sensitivity warnings available if one wants them, as long as they are off by default. -------------------------| John L. Ries | Salford Systems | Phone: (619)543-8880 x23 | Cell: (760)445-6122 | ------------------------- On Mon, 13 Sep 2004, Scott Moore wrote: > 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. > > -- > Samiam is Scott A. Moore > > Personal web site: http:/www.moorecad.com/scott > My electronics engineering consulting site: http://www.moorecad.com > ISO 7185 Standard Pascal web site: http://www.moorecad.com/standardpascal > Classic Basic Games web site: http://www.moorecad.com/classicbasic > The IP Pascal web site, a high performance, highly portable ISO 7185 Pascal > compiler system: http://www.moorecad.com/ippas > > Being right is more powerfull than large corporations or governments. > The right argument may not be pervasive, but the facts eventually are. > > >
Previous mail
Next mail
Unformatted/full headers
Overview 10 days
Subject
Date
Thread
Author
Note: This page contains information that does not originate from the owner of this web site, but from the authors of the mails archived. The owner of this web site is not responsible for the content of such information. Any use of that infomation requires the consent of the respective author.
Where WWW addresses (URLs) in the mails archived are marked as hyperlinks, this is only for the comfort of the reader. The content of the web pages linked to like this does not necessarily reflect the opinion of the owner of this web site or of the authors of the mails archived. The owner of this web site is not responsible for the content of such web pages. Those pages are explicitly not to be considered as part of the content of this page, but merely as references.
This page was created by Crystal 0.999 (Linux 2.4.27/i686).