henry@utzoo.uucp (Henry Spencer) (04/22/89)
In article <13159@dartvax.Dartmouth.EDU> jskuskin@eleazar.dartmouth.edu (Jeffrey Kuskin) writes: > Why is C case-sensitive? ... Why not? The real question is why things should be case-*in*sensitive. Uppercase and lowercase are different in appearance and in English usage; why should they be synonymous in a programming language? -- Mars in 1980s: USSR, 2 tries, | Henry Spencer at U of Toronto Zoology 2 failures; USA, 0 tries. | uunet!attcan!utzoo!henry henry@zoo.toronto.edu
djones@megatest.UUCP (Dave Jones) (04/22/89)
From article <1989Apr21.194615.5344@utzoo.uucp>, by henry@utzoo.uucp (Henry Spencer): > In article <13159@dartvax.Dartmouth.EDU> jskuskin@eleazar.dartmouth.edu (Jeffrey Kuskin) writes: >> Why is C case-sensitive? ... > > Why not? The real question is why things should be case-*in*sensitive. And the real answer is... (ta ta!) ... so you can talk to other engineers about the program without saying, "The first A is capitalized, and the S in Set, and ... no not that one..." Somewhere or another I heard of the "telephone test" for programs. I'm sorry I can't credit the author. The test, which is for judging the self-documentation properties of a program, is whether or not you can read it to someone over the telephone, and in doing so convey the meaning of the program. I determined then, that if I ever write my dream-language, it's identifiers at least will pass the telephone test. The language will not only not distinguish case, but underscores will not be significant in indentifiers. Of course, there would be a way to distinguish a canonical spelling for an identifier, for purposes of external linkage, probably the way it was spelled in the declaration. And there would need to be a ctags-like program which knew about the convention.
bobmon@iuvax.cs.indiana.edu (RAMontante) (04/23/89)
djones@megatest.UUCP (Dave Jones) <4402@goofy.megatest.UUCP> : - -... so you can talk to other engineers about the program without -saying, "The first A is capitalized, and the S in Set, and ... no not -that one..." Better you should simply name that first A as "capital A". And if you're talking to an engineer who gets the wrong letter from "the S in Set" then you have major difficulties beyond case-sensitivity. I once had the pleasure of reading a rookie engineer's first technical report, written in ALL UPPER CASE. IT WAS SHEER AGONY. IT SET HER CAREER BACK BY THE AMOUNT OF TIME IT TOOK HER TO COMPLETE AN IN-HOUSE TECHNICAL WRITING COURSE. - -I determined then, that if I ever write my dream-language, it's identifiers -at least will pass the telephone test. The language will not only -not distinguish case, but underscores will not be significant -in indentifiers. Of course, there would be a way to distinguish a And in this language, will "foon" and "phoon" be syntactically identical? I can't recall EVER wanting to communicate a program to someone orally, either over a phone (excuse me, fohn) or in person. When I have to, I specify it character by character, and if some of those characters are uppercase, or are blanks, or are oddball printable characters, I name them as such. This telephone test sounds utterly ill-conceived to me.
chris@mimsy.UUCP (Chris Torek) (04/23/89)
I have another answer. If you ignore case, you are discarding information. This is bad. If the programmer wants the information discarded, it% can do this itself: tr A-Z a-z < foo.c | /lib/cpp | /lib/ccom | /lib/c2 | as -o foo.o ----- % Non-sexist non-animist pronoun. ----- More seriously: I have used languages that ignore case, and languages that care about case, and have never been particularly impressed with the former, nor particularly excited about the case distinctions in the latter. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris
gwyn@smoke.BRL.MIL (Doug Gwyn) (04/23/89)
In article <4402@goofy.megatest.UUCP> djones@megatest.UUCP (Dave Jones) writes: >I determined then, that if I ever write my dream-language, it's identifiers >at least will pass the telephone test. The "telephone test" seems no more relevant for programming language design than it is for the validity of English grammar. Your quoted sentence passes the "telephone test" despite its erroneous use of the contraction "it's" for the possessive pronoun "its".
bill@twwells.uucp (T. William Wells) (04/23/89)
In article <17061@mimsy.UUCP> chris@mimsy.UUCP (Chris Torek) writes:
: More seriously: I have used languages that ignore case, and languages
: that care about case, and have never been particularly impressed with
: the former, nor particularly excited about the case distinctions in the
: latter.
I use the case of identifiers to tell me some important bits of
information about the identifier that are not properly conveyed by the
name. Here's my table:
identifier a local variable, a function, or structure or union member
Identifier a global variable
IDENTIFIER a #define constant, a typedef name, or a tag
identifier(...) a function-like macro
IDENTIFIER(...) a macro that evaluates its arguments more than once,
references locals, or does other wierd things
(I don't use enumerated types for portability reasons but they'd be
treated like #define constants. And I don't use labels and have no
plans for including them; after 6 years of programming C without gotos
I don't think they matter.)
Having these distinctions made consistently makes reading the code
much easier.
---
Bill { uunet | novavax } !twwells!billdiamond@diamond.csl.sony.junet (Norman Diamond) (04/24/89)
>In article <13159@dartvax.Dartmouth.EDU> jskuskin@eleazar.dartmouth.edu (Jeffrey Kuskin) writes: >> Why is C case-sensitive? ... In article <1989Apr21.194615.5344@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes: >Why not? The real question is why things should be case-*in*sensitive. >Uppercase and lowercase are different in appearance and in English usage; >why should they be synonymous in a programming language? You mean: WHY NOT? THE REAL QUESTION IS WHY THINGS SHOULD BE CASE-*IN*SENSITIVE. UPPERCASE AND LOWERCASE ARE DIFFERENT IN APPEARANCE AND IN ENGLISH USAGE; WHY SHOULD THEY BE SYNONYMOUS IN A PROGRAMMING LANGUAGE? Ugly yes, sometimes difficult to read yes, different in usage maybe, but as for not being synonymous..... Come on Henry, you wouldn't want to have to distinguish identifiers named myFunc and myfunc, when reading someone else's code. If you don't want to have myFunc map onto myfunc (i.e. not be synonymous) then suggest a require- ment that all occurences of an identifier be consistent in case, but it is silly to permit two distinct identifiers to differ only in case. >Mars in 1980s: USSR, 2 tries, | Henry Spencer at U of Toronto Zoology >2 failures; USA, 0 tries. | uunet!attcan!utzoo!henry henry@zoo.toronto.edu Canada, 0 tries. Norman Diamond, Sony Computer Science Lab (diamond%csl.sony.jp@relay.cs.net) The above opinions are my own. | Why are programmers criticized for If they're also your opinions, | re-inventing the wheel, when car you're infringing my copyright. | manufacturers are praised for it?
sam@lfcs.ed.ac.uk (S. Manoharan) (04/24/89)
Bill ({ uunet | novavax } !twwells!bill) writes: >In article <17061@mimsy.UUCP> chris@mimsy.UUCP (Chris Torek) writes: : More seriously: I have used languages that ignore case, and languages : that care about case, and have never been particularly impressed with : the former, nor particularly excited about the case distinctions in the : latter. >I use the case of identifiers to tell me some important bits of >information about the identifier that are not properly conveyed by the >name. Here's my table: >Having these distinctions made consistently makes reading the code much easier. > Having two ids foo and FOO that mean two different things will sure lead to confusion. If one accepts this, how would a case-insensitive language not support readabiltity? And how would a case-sensitive lang make the id-name space larger? Voice: 031-667 5076 S. Manoharan Janet: sam@uk.ac.ed.lfcs Dept of Computer Science Uucp : ..!mcvax!ukc!lfcs!sam University of Edinburgh Arpa : sam%lfcs.ed.ac.uk@nss.cs.ucl.ac.uk Edinburgh EH9 3JZ UK.
barmar@think.COM (Barry Margolin) (04/25/89)
This discussion is losing its specificity to C, so I've directed followups to comp.lang.misc. In article <10182@socslgw.csl.sony.JUNET> diamond@csl.sony.junet (Norman Diamond) writes: >Come on Henry, you wouldn't want to have to distinguish identifiers named >myFunc and myfunc, when reading someone else's code. If you don't want to >have myFunc map onto myfunc (i.e. not be synonymous) then suggest a require- >ment that all occurences of an identifier be consistent in case, but it is >silly to permit two distinct identifiers to differ only in case. So long as such things are not used haphazardly, case differences can be useful. For instance, in a language that doesn't permit some kind of delimiter (e.g. underscores or hyphens) in identifiers, it's possible that there could be two procedures named ReAdjustOneToken and ReadJustOneToken (I know, I'm stretching); case is being used as a delimiter, and it's completely obvious which one is which (but readjustonetoken would be a poor name for either). At a previous place of employment, case distinctions were often part of some developers' or groups' programming conventions. For instance, parameters to top-level procedures might be named P_xxx, while parameters to internal procedures would be named p_xxx. Another group used uppercase prefixes and suffixes to indicate data type; e.g. fooP would be a pointer to a foo (we used PL/I, which doesn't have typed pointers), but foop would be something else (and foopP would be a pointer to a foop). I've used both case-sensitive languages and case-insensitive languages. They both have their advantages and disadvantages. Case distinction, if used carefully, can be a good tool. It's easy to ignore when you aren't concerned about the attribute it represents, and easy to notice when you are. Barry Margolin Thinking Machines Corp. barmar@think.com {uunet,harvard}!think!barmar
c08_dta7@jhunix.HCF.JHU.EDU (TA7) (04/25/89)
In article <10182@socslgw.csl.sony.JUNET> diamond@csl.sony.junet (Norman Diamond) writes: >Come on Henry, you wouldn't want to have to distinguish identifiers named >myFunc and myfunc, when reading someone else's code. If you don't want to >have myFunc map onto myfunc (i.e. not be synonymous) then suggest a require- >ment that all occurences of an identifier be consistent in case, but it is >silly to permit two distinct identifiers to differ only in case. Making C case sensitive has at least two important advantages: 1- Compilation is faster because there is no need to map upper case characters to lower case characters, or vice-versa. 2- If the compiler is case insensitive then many Pascal programmers will create such horrors as: INT MAIN(INT ARGC, CHAR *ARGV[]) {} Also, there is the controvertial advantage: One may have a constant with the same name as a variable or a function. I think the main reason for it is the general philosophy of C: You assume the programmer knows what he is doing. You give him tools that can be used to create a mess, and assume that the programmer is smart enough to be able to use this power to create efficient programs. As a result of this philosophy, there is no comparison between the size or efficiency of C programs with their Pascal counterparts. Mamdouh Maher
ddb@ns.network.com (David Dyer-Bennet) (04/25/89)
In article <1989Apr21.194615.5344@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes: :In article <13159@dartvax.Dartmouth.EDU> jskuskin@eleazar.dartmouth.edu (Jeffrey Kuskin) writes: :> Why is C case-sensitive? ... : :Why not? The real question is why things should be case-*in*sensitive. :Uppercase and lowercase are different in appearance and in English usage; :why should they be synonymous in a programming language? In most cases (sorry), casing in English doesn't distinguish this word from another word spelled identically; rather, it identifies a word that's at the beginning of a sentence. Or it identifies a non-word such as an acronym; but most people just accept those as normal words, regardless of the casing. Also, in text ALL CAPS is often used for emphasis, without confusing anybody about which words are meant. Casing rules in English are generally formal, not substantive, and therefore I consider case to be essentially not significant in normal English usage. -- David Dyer-Bennet, ddb@terrabit.fidonet.org, or ddb@ns.network.com or ddb@Lynx.MN.Org, ...{amdahl,hpda}!bungia!viper!ddb or ...!{rutgers!dayton | amdahl!ems | uunet!rosevax}!umn-cs!ns!ddb or Fidonet 1:282/341.0, (612) 721-8967 9600hst/2400/1200/300
djones@megatest.UUCP (Dave Jones) (04/25/89)
From article <19925@iuvax.cs.indiana.edu>, by bobmon@iuvax.cs.indiana.edu (RAMontante): ... > > I can't recall EVER wanting to communicate a program to someone orally, > either over a phone (excuse me, fohn) or in person. > It's not so much whether you want to or not, it's just that in the real world of engineering, one is continually discussing programs with other people. Every day. > When I have to, I > specify it character by character, and if some of those characters are > uppercase, or are blanks, or are oddball printable characters, I name > them as such. > If you have to transcribe an entire program precisely, you use a tape or a floppy, for Pete's sake. I'm talking about how you conduct conversations about programs, not how you transcribe them.
djones@megatest.UUCP (Dave Jones) (04/25/89)
From article <10097@smoke.BRL.MIL>, by gwyn@smoke.BRL.MIL (Doug Gwyn): > In article <4402@goofy.megatest.UUCP> djones@megatest.UUCP (Dave Jones) writes: >>I determined then, that if I ever write my dream-language, it's identifiers >>at least will pass the telephone test. > > The "telephone test" seems no more relevant for programming language > design than it is for the validity of English grammar. Your quoted > sentence passes the "telephone test" despite its erroneous use of the > contraction "it's" for the possessive pronoun "its". Oh come on, Doug. That doesn't make any sense. Admit it: You just invented an excuse for pointing out my little mistake. You're net.pedant, Dave Jones
djones@megatest.UUCP (Dave Jones) (04/25/89)
> In article <17061@mimsy.UUCP> chris@mimsy.UUCP (Chris Torek) writes: > > I use the case of identifiers to tell me some important bits of > information about the identifier that are not properly conveyed by the > name. Here's my table: > > identifier a local variable, a function, or structure or union member > Identifier a global variable > IDENTIFIER a #define constant, a typedef name, or a tag > identifier(...) a function-like macro > IDENTIFIER(...) a macro that evaluates its arguments more than once, > references locals, or does other wierd things > I too use capitalization conventions in C. But I also try to remember to distinguish things by spelling also, particularly if the two identifiers might be valid in the same context. If the compiler of some other language did not distinguish case, I would still use capitalization conventions, as an aid to the reader. The discussion is about whether the "extra information" in capitolization is best treated as significant or redundant. Dave
wen-king@cit-vax.Caltech.Edu (King Su) (04/25/89)
< Why is C case-sensitive? ...
A: It makes life very much simpler for many experienced C-programmers.
With case sensitivity, they get 26 more symbols for free. :-)
--
/*------------------------------------------------------------------------*\
| Wen-King Su wen-king@vlsi.caltech.edu Caltech Corp of Cosmic Engineers |
\*------------------------------------------------------------------------*/friedl@vsi.COM (Stephen J. Friedl) (04/25/89)
Henry signs: >Mars in 1980s: USSR, 2 tries, | Henry Spencer at U of Toronto Zoology >2 failures; USA, 0 tries. | uunet!attcan!utzoo!henry henry@zoo.toronto.edu Norm Diamond writes: > Canada, 0 tries. Norm, that's not fair; Canada's not a real country. :-) :-) :-) :-) <---- flame shield :-) Steve :-) :-) :-) :-) :-) -- Stephen J. Friedl / V-Systems, Inc. / Santa Ana, CA / +1 714 545 6442 3B2-kind-of-guy / friedl@vsi.com / {attmail, uunet, etc}!vsi!friedl As long as Bush is in office, you'll never see Nancy Reagan in *my* .sig.
dokos@inmet (04/25/89)
The "telephone test" is mentioned on p.21 of Kernighan & Plauger's "Elements of Programming Style". It probably did not originate with them - they surround it with quotation marks too. Nick Dokos dokos@inmet.inmet.com uunet!inmet!dokos
clt@pur-phy (Carrick Talmadge) (04/25/89)
In article <10182@socslgw.csl.sony.JUNET> diamond@csl.sony.junet (Norman Diamond) writes: > [...] it is silly to permit two distinct identifiers to differ only in case. Here is a real life example where I personally would want the case to be sensitive. Nobody in physics who reads this would have any problem with the notation, or would complain about readability problems arising from reusing the same variable name with upper and lower case. /* * Calculate gravitational acceleration of an oblate spheroid */ #include <math.h> double G = 6.6726e-11; /* Newtonian constant of gravity (MKS units) */ double R = 6.3710159e6; /* mean radius of the Earth (meters) */ double J2 = 1.0826347e-3; /* quadrupole moment of the Earth. */ double g; /* acceleration of gravity (MKS units) */ double r; /* distance from CM of spheroid to satellite */ /* etc. */ Obligatory moralizing omitted... Carrick Talmadge ARPA: clt@physics.purdue.edu USENET: ...!pur-ee!pur-phy!clt BITNET: talmadge@purccvm.bitnet
dmg@ssc-vax.UUCP (David Geary) (04/26/89)
S. Manoharan writes: Bill ({ uunet | novavax } !twwells!bill) writes: ::: In article <17061@mimsy.UUCP> chris@mimsy.UUCP (Chris Torek) writes: ::: More seriously: I have used languages that ignore case, and languages ::: that care about case, and have never been particularly impressed with ::: the former, nor particularly excited about the case distinctions in the ::: latter. I agree. :: I use the case of identifiers to tell me some important bits of :: information about the identifier that are not properly conveyed by the :: name. Here's my table: Whatever the table was, it's gone ;-). I assume the table was a table such as: FUNCTIONS SomeName() MACROS WITH TOKENS somename() DEFINED CONSTATNS SOMENAME VARIABLES some_name :: Having these distinctions made consistently makes reading the code :: much easier. Agreed. : Having two ids foo and FOO that mean two different things will sure : lead to confusion. If one accepts this, Maybe. Consider: 1) Whenever I write code I stick to a convention similar to the table above. 2) Whenever I write code "professionally" (meaning it may someday be meant for public consumption), I insert a comment at the top of the file containing main(), (and possibly in other files where I feel it's appropriate), that shows the table of conventions I use in my code. If the author states his conventions, and sticks with the conventions then I believe case-sensitivity IMPROVES the readability of the code. Therefore, if one came across the following code fragment: for(max_names = 0; max_names < MAX_NAMES; ++max_names) ... it would be immediately obvious that MAX_NAMES was a defined constant, and max_names was a variable. Realize that I consider the choice of name "max_names" for the variable above bad style. max_names does not convey the purpose of the variable accurately. It should be named name_counter or something similar to indicate that it is counting names. However, that does not mean that it is difficult to distinguish max_names from MAX_NAMES. Along the same vein then, I agree that having two "ids" foo and FOO is ABT (A Bad Thing). But it's not ABT because it's difficult to distinguish which foo is FOO. The moral of the story is that, just like any other feature of a programming language, C's case sensitivity CAN be used in a haphazard manner, that creates incomprehensible code. (See the thread on the comma operator currently being discussed). I can use goto's to create disguisting code. I can use commas to create hard to understand code. I can use case sensitivity, etc. However, just as is the case with many features of C, when used consistently, and in the right contexts, case sensitivity can be used to one's advantage. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~ David Geary, Boeing Aerospace, Seattle ~ ~ "I wish I lived where it *only* rains 364 days a year" ~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
) Seaman) (04/26/89)
diamond@diamond.csl.sony.junet (Norman Diamond) writes: < >jskuskin@eleazar.dartmouth.edu (Jeffrey Kuskin) writes: < < >> Why is C case-sensitive? ... < < henry@utzoo.uucp (Henry Spencer) writes: < < >Why not? The real question is why things should be case-*in*sensitive. < >Uppercase and lowercase are different in appearance and in English usage; < >why should they be synonymous in a programming language? < < Come on Henry, you wouldn't want to have to distinguish identifiers named < myFunc and myfunc, when reading someone else's code. If you don't want to < have myFunc map onto myfunc (i.e. not be synonymous) then suggest a require- < ment that all occurences of an identifier be consistent in case, but it is < silly to permit two distinct identifiers to differ only in case. < < >Henry Spencer at U of Toronto Zoology < < Norman Diamond, Sony Computer Science Lab (diamond%csl.sony.jp@relay.cs.net) As a matter of fact, I WOULD want to have to distinguish identifiers named myFunc, myfunc, Myfunc, MyFunc, and MYFUNC. I have done this in the past, for example, when I typedef a struct to 'NODE', then declare a variable as 'NODE *node'. I find this quite easy to read. People have been saying things such as, "Humans are case-insensitive". Note my use of 'WOULD' above, as opposed to 'would'. This is due to the fact that I intended a stronger, and therefore, different, meaning of the word. Humans are case sensitive to the point that a simple change in inflection can radically alter the meaning of a word or phrase. Also, we are case sensitive in that I do take the word 'Tree' to mean something other than 'tree'. The word 'Tree' would either be a proper name, i.e. 'George, meet Tree; Tree, meet George', or at least the beginning of a sentence. The word 'tree' refers to any of the hundreds of varieties of woody plants, some growing to heights in excess of a hundred feet. All this aside, C (that's a capital c) IS a case sensitive language, so if someone wants to use it as a case-insensitive one, then just don't use the shift key :-). -- Chris Seaman | o\ /o crs@cpsc6a.att.com <or> | || See "Attack of the Killer Smiley"! ..!ihnp4!cpsc6a!crs | \vvvvvv/ Coming Soon to a newsgroup near you! | \____/
zougas@me.utoronto.ca ("Athanasios(Tom) Zougas") (04/26/89)
In article <1105@vsi.COM> friedl@vsi.COM (Stephen J. Friedl) writes: >Henry signs: >>Mars in 1980s: USSR, 2 tries, | Henry Spencer at U of Toronto Zoology >>2 failures; USA, 0 tries. | uunet!attcan!utzoo!henry henry@zoo.toronto.edu > >Norm Diamond writes: >> Canada, 0 tries. > >Norm, that's not fair; Canada's not a real country. > > :-) :-) :-) :-) <---- flame shield > :-) Steve :-) > :-) :-) :-) :-) > We have billions of dollars in deficit, just like a real country. BTW, this thread doesn't belong here. Someone get it outta here. Tom. -- This is my signature: tom zougas
tainter@ihlpb.ATT.COM (Tainter) (04/26/89)
In article <1831@etive.ed.ac.uk> sam@lfcs.ed.ac.uk (S. Manoharan) writes: >>I use the case of identifiers to tell me some important bits of >>information about the identifier that are not properly conveyed by the >>name. Here's my table: >Having two ids foo and FOO that mean two different things will sure >lead to confusion. If one accepts this, >how would a case-insensitive language not support readabiltity? But, we don't accept this! Unless someone is reading the symbols out loud (see the silly, SILLY phone test discussion) people are not going to confuse these. Show me proof that someone able to otherwise understand the language will get confused by this. Use of case sensitivity in mathematics has not seriously interfered with its readability. >Voice: 031-667 5076 S. Manoharan --johnathan.a.tainter-- att!ihlpb!tainter
bill@twwells.uucp (T. William Wells) (04/26/89)
In article <1831@etive.ed.ac.uk> sam@lfcs.ed.ac.uk (S. Manoharan) writes: : Bill ({ uunet | novavax } !twwells!bill) writes: : >I use the case of identifiers to tell me some important bits of : >information about the identifier that are not properly conveyed by the : >name. Here's my table: : : : >Having these distinctions made consistently makes reading the code : much easier. : > : : Having two ids foo and FOO that mean two different things will sure : lead to confusion. If one accepts this, Only if confusion is possible to begin with. I agree that having ids foo and FOO where the two might be confused is a bad idea, but just having them isn't. For example, there is little wrong with this: typedef struct { ... } FOO; FOO *foo; Though I'd never write such (I'd call the pointer foop), there isn't any possible way to confuse FOO with foo. Be that as it may, I don't usually have names that differ only in case. This is (almost) not intentional, it is an artifact of other considerations. Going back to my original table, let me add some comments: identifier a local variable, a function, or structure or union member Locals are usually short, with just enough letters in them to make them mnemonic. Function names are usually long and spelled out. Structure and union members usually have a prefix relating them to their structures. Variables and members tend to be nouns; functions, verbs. Identifier a global variable These are usually long and spelled out. These tend to be nouns. IDENTIFIER a #define constant, a typedef name, or a tag #define names typically have an identifying prefix that is not used elsewhere. Typedef names and tags typically have a name whose semantic characteristics distinguish are such that other names don't have the same spelling. #define names are often nouns, typedef nouns tend to be adjectives. identifier(...) a function-like macro These are often long and spelled out. They tend to be verbs. IDENTIFIER(...) a macro that evaluates its arguments more than once, references locals, or does other wierd things These are often long and spelled out. These tend to be verbs. As you can see, there is little scope for duplicating the spelling of names with but case for difference. Because of these consideratios, even in the occasional case that I do duplicate, there is rarely the possibility of confusing the reader. Confusion is the bottom line: if it is the case that I have two names that are similar enough that the reader might be confused, I will change one of them. This applies to more than just case differences. Consider the difference between foo1 and fool. The confusion argument against case sensitivity would, consistently applied, also require us to consider `1' to be the same as 'l'. Hah. To hell with such ideological reasoning, just make the code easy to understand! BTW, I do make it a point to have globals and other externals differ after case is stripped. One must, for portability. I'm told, e.g., that when you compile code for Microsoft Windows, you must tell the linker to ignore case because of some stupidity that Microsoft did. --- Bill { uunet | novavax } !twwells!bill
diamond@diamond.csl.sony.junet (Norman Diamond) (04/26/89)
Henry signs: >>>Mars in 1980s: USSR, 2 tries, | Henry Spencer at U of Toronto Zoology >>>2 failures; USA, 0 tries. | uunet!attcan!utzoo!henry henry@zoo.toronto.edu I added: >> Canada, 0 tries. In article <1105@vsi.COM> friedl@vsi.COM (Stephen J. Friedl) writes: >Norm, that's not fair; Canada's not a real country. > > :-) :-) :-) :-) <---- flame shield > :-) Steve :-) > :-) :-) :-) :-) Steve's personal e-mail to me was considerably more reasonable. I hereby violate netiquette and quote it in full: > Touche' You should have posted that one instead, Steve. Well Steve, as Japanese people could tell you, the U.S.A. also is not a real country. Didn't even pick a name for itself; it had to steal its continent's name instead. (Hmm, is that why it sometimes thinks it's the entire continent?) Incidentally, I just saw "For All Mankind" and had to laugh at the U.S.A.'s flag being spread out for all mankind. When Christopher Columbus planted the Spanish flag, he didn't pretend that he was claiming the Amerinds' land for all mankind; he knew it rightfully belonged to Spain. Maybe this posting isn't fair; the astronauts had better flame shields. What's this doing in comp.lang.c? Follow-ups redirected to /dev/null. Norman Diamond, Sony Computer Science Lab (diamond%csl.sony.jp@relay.cs.net) The above opinions are my own. | Why are programmers criticized for If they're also your opinions, | re-inventing the wheel, when car you're infringing my copyright. | manufacturers are praised for it?
chris@mimsy.UUCP (Chris Torek) (04/26/89)
In article <4416@goofy.megatest.UUCP> djones@megatest.UUCP (Dave Jones) appears to claim that >>In article <17061@mimsy.UUCP> chris@mimsy.UUCP (Chris Torek) writes: >> >>I use the case of identifiers to ... but in fact the `>>' text was written by Bill Wells, as one can see from the References header and from the fact that followup attributions normally read In article A user@A writes: >In article B user@B writes: >>text by user@B, with two >> marks >text by user@A, with one > mark Be careful with those attributions. . . . -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris
diamond@diamond.csl.sony.junet (Norman Diamond) (04/26/89)
In article <1562@jhunix.HCF.JHU.EDU> c08_dta7@jhunix.UUCP (TA7) writes: > 2- If the compiler is case insensitive then many Pascal programmers will > create such horrors as: INT MAIN(INT ARGC, CHAR *ARGV[]) {} I don't know any Pascal programmers who code like this. I used to code IBM mainframes like this because keypunches were monocase, but those predated Pascal. > Also, there is the controvertial advantage: One may have a >constant with the same name as a variable or a function. Yup, that's a considerable advantage when you're maintaining someone else's code. You get to spend a lot longer reading lots more of his program, so you become more familiar with it and you get paid more (unless your overtime is free). Yup, many advantages. >I think the main reason for it is the general philosophy of C: You >assume the programmer knows what he is doing. You give him tools that >can be used to create a mess, and assume that the programmer is smart >enough to be able to use this power to create efficient programs. That's why you don't ever need a debugger, right? And especially not lint, right? We certainly don't a programmer to have to SAY that he knows what he's doing. That might let us find out that he knew what he MEANT to do, only his fingers hit the wrong keys. Hmm, why did ANSI accept the idea of prototypes, and strong type checking of structures? We'd better get all those Pascal groupies off the ANSI C committee! Why does rn put "usr/lib/news/organization" in the Organization field of my postings? Obviously the programmer knew what he was doing. I shouldn't go back and edit this one. >As a >result of this philosophy, there is no comparison between the size or >efficiency of C programs with their Pascal counterparts. Huh? Norman Diamond, Sony Computer Science Lab (diamond%csl.sony.jp@relay.cs.net) The above opinions are my own. | Why are programmers criticized for If they're also your opinions, | re-inventing the wheel, when car you're infringing my copyright. | manufacturers are praised for it?
bill@twwells.uucp (T. William Wells) (04/26/89)
In article <1320@ns.network.com> ddb@ns.UUCP (David Dyer-Bennet) writes:
: Casing rules in English are generally formal, not substantive, and
: therefore I consider case to be essentially not significant in normal
: English usage.
March vs. march?
May vs. may?
August vs. august?
John vs. john?
Mark vs. mark?
French vs. french?
German vs. german?
House vs. house?
Governor vs. governor?
And then consider German, where all nouns are capitalized.
But of course, this is all neither here nor there. Language is a just
a tool; we should shape the tool to meet our purposes, not some
arbitrary ideology. Deciding that C shouldn't have case sensitivity
because English doesn't is like deciding that one shouldn't split
infinitives in English because it can't be done in Latin.
(Sorry, I'm not up to constructing that last sentence with a split
infinitive that you won't even notice, much less cavil at. But did
you notice that the previous sentence ended in a preposition? Heresy!)
---
Bill { uunet | novavax } !twwells!billbengsig@oracle.nl (Bjorn Engsig) (04/26/89)
In article <1320@ns.network.com> ddb@ns.UUCP (David Dyer-Bennet) writes: > >In most cases (sorry), casing in English doesn't distinguish ... > ... [deletions] >Casing rules in English are generally formal, not substantive, and >therefore I consider case to be essentially not significant in normal >English usage. What does the use of upper and lower case in English has to do with C programming? Should we also use other aspects of written natural text such as syntax, semantics, how to typeset, punctuation, etc. in C? We could also try to let C look like cobol :-) No, let's continue with the current well-established use of lower/upper case, and not fight any longer about minor details. -- Bjorn Engsig, ORACLE Europe \ / "Hofstadter's Law: It always takes Path: mcvax!orcenl!bengsig X longer than you expect, even if you Domain: bengsig@oracle.nl / \ take into account Hofstadter's Law"
jlg@lanl.gov (Jim Giles) (04/27/89)
From article <124200014@inmet>, by dokos@inmet: > The "telephone test" is mentioned on p.21 of Kernighan & Plauger's > "Elements of Programming Style". It probably did not originate with > them - they surround it with quotation marks too. They only apply it to reading boolean expressions too. This is a very narrow interpretation of the "telephone test", and I agree with them that it may be one of the few contexts where the "telephone test" is really very valuable.
djones@megatest.UUCP (Dave Jones) (04/27/89)
From article <10322@ihlpb.ATT.COM>, by tainter@ihlpb.ATT.COM (Tainter): > > See the silly, SILLY phone test discussion > mE? SiLLy? mE? nO wAy, joSE! YoU'Re sIlly. SillY sIllY SilLy. NyaHh! Dave "Putty-Nose" Jones
enevill@acorn.co.uk (Edward Nevill) (04/27/89)
In article <4402@goofy.megatest.UUCP>, djones@megatest.UUCP (Dave Jones) writes: > > In article <13159@dartvax.Dartmouth.EDU> jskuskin@eleazar.dartmouth.edu (Jeffrey Kuskin) writes: > >> Why is C case-sensitive? ... > > > > Why not? The real question is why things should be case-*in*sensitive. I don't have a problem with case [in]sensitivity in languages. I do have a problem with people who write mixed case library functions for case sensitive languages, eg. Mac C systems. Turning to a random page in Inside Macintosh. Pg. I-474 FUNCTION GetCursor(cursorID: INTEGER) : CursHandle; TYPE CursPtr = ^Cursor; CursHandle = ^CursPtr; CONST iBeamCursor = 1; crossCursor = 2; plusCursor = 3; watchCursor = 4; PROCEDURE ShieldCursor(shieldRect: Rect; offsetPt: Point); This is enough to drive anyone up the wall. The case usage isn't even consistent. I find that, even though I know perfectly well how the identifier should be spelled, I continually have to look up the manual to find the correct case. This is a pain. > Somewhere or another I heard of the "telephone test" for programs. > I'm sorry I can't credit the author. The test, which is for judging the > self-documentation properties of a program, is whether or not you > can read it to someone over the telephone, and in doing so convey the > meaning of the program. The 'Telephone Test' has been surperceeded by the Modem :-) Edward Nevill (enevill@acorn.co.uk)
billd@celerity.UUCP (Bill Davidson) (04/27/89)
This is getting really boring folks. Can't we let this one die? It's an issue not worth arguing about since it is *not* going to change. It could break a fair amount of code (probably with the pre-processor). If you don't like C being case sensitive, then why don't you write in Pascal or Fortran or some other non-case sensitive language? If you have nothing better to do than to bitch about something as unimportant as this, you probably were not meant to be a C programmer anyway. (Oh no, I violated section 3.2 of "How to Use USENET Effectively" I'm so ashamed). Bill Davidson ...!ucsd!celerity!billd
dg@lakart.UUCP (David Goodenough) (04/27/89)
From article <1320@ns.network.com>, by ddb@ns.network.com (David Dyer-Bennet): F In article <1989Apr21.194615.5344@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes: O :In article <13159@dartvax.Dartmouth.EDU> jskuskin@eleazar.dartmouth.edu (Jeffrey Kuskin) writes: O :> Why is C case-sensitive? ... L : - :Why not? The real question is why things should be case-*in*sensitive. I :Uppercase and lowercase are different in appearance and in English usage; N :why should they be synonymous in a programming language? E W ..... Also, in text ALL CAPS is often used for S emphasis, without confusing anybody about which words are meant. Precisely. That's why one convention _IS_ to use uppercase for manifest constants, and lower case for most everything else: #define SIZE 64 char string[SIZE]; etc. etc. etc. etc. > Casing rules in English are generally formal, not substantive, and > therefore I consider case to be essentially not significant in normal > English usage. Granted, they would have very little effect on the comprehensibility of the printed matter, but in a companion posting I'll show that the rules are important. As Rahul Dhesi pointed out: eNGliSh iS A CASe seNSiTive lANguAgE This can be read, but I'll bet it doesn't read _QUITE_ as fast as English is a case sensitive language. (Food for thought - coments welcome) Perhaps _THAT'S_ why we capitalise for emphasis - it creates a tiny "slow down" thus drawing attention to the text we want to emphasize. -- dg@lakart.UUCP - David Goodenough +---+ IHS | +-+-+ ....... !harvard!xait!lakart!dg +-+-+ | AKA: dg%lakart.uucp@xait.xerox.com +---+
dg@lakart.UUCP (David Goodenough) (04/27/89)
FROm arTICle <1320@NS.NETwork.cOM>, by dDb@NS.NEtworK.Com (david dYEr-BenNET): F IN aRTIcLE <1989aPr21.194615.5344@utZoO.UuCP> heNRy@uTZoo.uuCp (henrY speNcer) WRIteS: O :iN ARTICLe <13159@dArtvax.dARtmOUTH.edu> jskuSKIN@EleAZAr.DArTMoUTh.edU (JeFFREy KUSkin) WRiteS: o :> Why is c CaSe-sEnSiTive? ... l : - :wHy Not? tHe Real qUEstiOn IS Why THiNGS shouLd bE CAsE-*iN*SenSITIVE. i :UPPercaSe aND lOweRcAsE Are DiFfeRENT iN appEaraNce anD IN eNgLISH usAge; N :WHY SHoULd THEy bE SyNonyMOus in a PRogrAMmiNg LAngUaGE? E w ..... AlSo, IN TExT ALl CaPS is OFtEn uSeD FOr S EmpHasIs, wITHout CONfuSiNG AnyBoDy AbouT wHIcH WorDs aRE meanT. PReCIsELy. ThAt's why oNe COnvEntion _is_ To uSe UpPErcAse fOr manifest CoNstaNts, AnD loWER CaSe FoR MOsT eVerythiNg else: #defINe sIzE 64 cHAR STRiNg[sIzE]; etC. eTC. EtC. ETc. > CAsiNG RUlES iN EnGlISH ArE geNERAllY FORmAL, NOT suBstAntive, AnD > THeRefORe I consIDEr caSe To Be ESsentIalLy noT SIgnIfICANT in NormaL > EngLiSh usAGE. gRANTED, THEY WoULd Have vERY lITTlE EFFeCt oN THe coMPReHeNsiBILItY oF the prINtEd mAttEr, But iN a cOMPaNiON pOStINg I'LL sHOw thaT THE rULes arE ImpoRTanT. AS RahUL dhESI POintEd OuT: ENgLiSh IS a cAsE SensitIve lANGUAge THIs cAN BE rEaD, BUT i'lL bET iT doeSN'T rEaD _QuITe_ As FaST As ENgLIsh iS A CAsE sENsItive langUaGe. (FoOd FOR tHoUgHT - ComENTs wElcOME) PERhaps _tHAt'S_ WHy We cAPitAlise fOR EmphASis - it cREATEs a TINy "Slow dOWN" ThuS DRAWING atTeNTion to The tExt We WANt To eMphASizE. -- Dg@lAKARt.UUCP - DaVID gOODenoUGh +---+ Ihs | +-+-+ ....... !harvaRD!xAIT!LAKarT!Dg +-+-+ | aka: DG%LAKARt.uucp@XAit.xEroX.coM +---+ ---------------------------------------- Now. Does that read as easily as my previous posting??? You see why case sensitivity _DOES_ make a difference.
ddb@ns.network.com (David Dyer-Bennet) (04/28/89)
In article <871@twwells.uucp> bill@twwells.UUCP (T. William Wells) writes: :In article <1320@ns.network.com> ddb@ns.UUCP (David Dyer-Bennet) writes: :: Casing rules in English are generally formal, not substantive, and :: therefore I consider case to be essentially not significant in normal :: English usage. : : March vs. march? : May vs. may? : August vs. august? etc. But in practice nobody gets particularly bent out of shape if somebody writes "Well, then we won't have the blasted thing done until august, I guess." The formal convention is there, but it doesn't seem to be what people use for figuring out the meaning of the sentence. -- David Dyer-Bennet, ddb@terrabit.fidonet.org, or ddb@ns.network.com or ddb@Lynx.MN.Org, ...{amdahl,hpda}!bungia!viper!ddb or ...!{rutgers!dayton | amdahl!ems | uunet!rosevax}!umn-cs!ns!ddb or Fidonet 1:282/341.0, (612) 721-8967 9600hst/2400/1200/300
ddb@ns.network.com (David Dyer-Bennet) (04/28/89)
In article <319.nlhp3@oracle.nl> bengsig@oracle.nl (Bjorn Engsig) writes:
:What does the use of upper and lower case in English has to do with C
:programming?
The skill of reading, learned over 12 or so years sometimes even before
you ever write a computer program, is heavily used when writing (and
particularly when modifying) computer programs. My argument is that
changing the "reading rules" of the language, particularly, in this case,
the rules about case sensitivity, set up an unnecessary barrier to people
trying to acquire the programming skill, and continue to cause at least
low-level cognitive dissonance for some time (many years) after you've
surmounted the initial hurdle.
--
David Dyer-Bennet, ddb@terrabit.fidonet.org, or ddb@ns.network.com
or ddb@Lynx.MN.Org, ...{amdahl,hpda}!bungia!viper!ddb
or ...!{rutgers!dayton | amdahl!ems | uunet!rosevax}!umn-cs!ns!ddb
or Fidonet 1:282/341.0, (612) 721-8967 9600hst/2400/1200/300djones@megatest.UUCP (Dave Jones) (04/28/89)
From article <752@acorn.co.uk), by enevill@acorn.co.uk (Edward Nevill): ) ... I do have a problem with people who write mixed case library ) functions for case sensitive languages, eg. Mac C systems. ) Turning to a random page in Inside Macintosh. ) ) Pg. I-474 ) ) FUNCTION GetCursor(cursorID: INTEGER) : CursHandle; ) ) TYPE CursPtr = ^Cursor; ) CursHandle = ^CursPtr; ) ) CONST iBeamCursor = 1; ) crossCursor = 2; ) plusCursor = 3; ) watchCursor = 4; ) ) PROCEDURE ShieldCursor(shieldRect: Rect; offsetPt: Point); ) ) This is enough to drive anyone up the wall. ... Yeah, but with some of us it's a longer drive than with others. Anyway, we see another reason my "dream-language" will not distinguish case or underscores in identifiers: Spell it "iBeamCursor", or "Ibeamcursor", or "I_beam_cursor", or whatever you please; it would mean the same thing. No need to keep going back to the manuals to recall the blessed capitalization.
diamond@diamond.csl.sony.junet (Norman Diamond) (04/28/89)
In article <752@acorn.co.uk> enevill@acorn.co.uk (Edward Nevill) writes: >I don't have a problem with case [in]sensitivity in languages. I do have a >problem with people who write mixed case library functions for case sensitive >languages, eg. Mac C systems. Turning to a random page in Inside Macintosh. >Pg. I-474 >FUNCTION GetCursor(cursorID: INTEGER) : CursHandle; > >TYPE CursPtr = ^Cursor; > CursHandle = ^CursPtr; > >CONST iBeamCursor = 1; > crossCursor = 2; > plusCursor = 3; > watchCursor = 4; > >PROCEDURE ShieldCursor(shieldRect: Rect; offsetPt: Point); Mac C takes this? That must be some C compiler! >I continually have to look up the manual to find the >correct case. This is a pain. Well, if it's really a Pascal compiler, then you DON'T have to look up the correct spelling, because Pascal is case insensitive. Pascal formerly did not accept underscores (silly little painful omission which is now rectified), so designers used casing instead of underscores to delimit words for human readers. If this drives you up a wall, you'd better not use underscores or capitals in C either. At least in Pascal, the user of such a library could be lazy about matching the capitals (though a professional would not be). Norman Diamond, Sony Computer Science Lab (diamond%csl.sony.jp@relay.cs.net) The above opinions are my own. | Why are programmers criticized for If they're also your opinions, | re-inventing the wheel, when car you're infringing my copyright. | manufacturers are praised for it?
sam@lfcs.ed.ac.uk (S. Manoharan) (04/28/89)
Chris writes: > >As a matter of fact, I WOULD want to have to distinguish identifiers named >myFunc, myfunc, Myfunc, MyFunc, and MYFUNC. I have done this in the >past, for example, when I typedef a struct to 'NODE', then declare a >variable as 'NODE *node'. I find this quite easy to read. > >People have been saying things such as, "Humans are case-insensitive". >Note my use of 'WOULD' above, as opposed to 'would'. This is due to the >fact that I intended a stronger, and therefore, different, meaning of the >word. It is nice to have C case-sensitive. But the question is does it really expand the address space? Taking your example, you can have "would", "WOULD", and probably "Would". Sure, you wouldn't like to have "wouLd", "wOuld", etc. In effect, case-sensitivity helps the programmer to expand the address ( identifier, to be precise ) space by not more than three fold. Voice: 031-667 5076 S. Manoharan Janet: sam@uk.ac.ed.lfcs Dept of Computer Science Uucp : ..!mcvax!ukc!lfcs!sam University of Edinburgh Arpa : sam%lfcs.ed.ac.uk@nsfnet-relay.ac.uk Edinburgh EH9 3JZ UK.
bill@twwells.uucp (T. William Wells) (04/29/89)
In article <1331@ns.network.com> ddb@ns.UUCP (David Dyer-Bennet) writes:
: But in practice nobody gets particularly bent out of shape if somebody writes
: "Well, then we won't have the blasted thing done until august, I guess."
: The formal convention is there, but it doesn't seem to be what people use
: for figuring out the meaning of the sentence.
He is in the house.
vs.
He is in the House.
This is not a topic worth debating. The difference is in fact
substantive.
If you'd like an analogy, consider that, in C, pointer casts are
often, by the uninformed, considered formal rather than substantive
because it is often the case that the cast induces no change in the
representation.
This does not change the fact that casts are substantive.
And ignorance of this point has caused many C programmers grief.
Ignorance of the English point is much less likely to cause grief,
not because the difference is not substantive, but because English is
immensely redundant.
Followups have been directed to /dev/null.
---
Bill { uunet | novavax } !twwells!billseanf@sco.COM (Sean Fagan) (05/03/89)
In article <1331@ns.network.com> ddb@ns.UUCP (David Dyer-Bennet) writes: >But in practice nobody gets particularly bent out of shape if somebody writes >"Well, then we won't have the blasted thing done until august, I guess." >The formal convention is there, but it doesn't seem to be what people use >for figuring out the meaning of the sentence. Maybe, but consider: "We dropped a stick of dynamite down the pole and *whammo*!" versus "We dropped a stick of dynamite down the Pole and *whammo*!" One is likely to get you cited for vanalism, the other for murder. See what difference a little punctuation can make? -- Sean Eric Fagan | "An acid is like a woman: a good one will eat seanf@sco.UUCP | through your pants." -- Mel Gibson, Saturday Night Live (408) 458-1422 | Any opinions expressed are my own, not my employers'.
suitti@haddock.ima.isc.com (Stephen Uitti) (05/03/89)
In article <10193@socslgw.csl.sony.JUNET> diamond@csl.sony.junet (Norman Diamond) writes: >In article <752@acorn.co.uk> enevill@acorn.co.uk (Edward Nevill) writes: >>I do have a >>problem with people who write mixed case library functions for case sensitive >>languages, eg. Mac C systems. >>FUNCTION GetCursor(cursorID: INTEGER) : CursHandle; >>... >Mac C takes this? That must be some C compiler! You tranlate it to (ansi prototype form): CursHandle GetCursor(int cursorID); where CursHandle is a typedef somewhere. There is a paragraph in the LightSpeed C (LSC) documentation on how to do this. >>I continually have to look up the manual to find the >>correct case. This is a pain. > >Well, if it's really a Pascal compiler, then you DON'T have to look up >the correct spelling, because Pascal is case insensitive. The Mac was originally a Pascal machine. C came later. C for the Mac (LSC, for example) used Inside Macintosh for all definitions. No real attempt was made to translate Inside Mac to C as a document. Since C is case sensitive, and since Inside Mac is pretty consistent, the library is case sensitive. Oh well. It is historical. I prefer the way they did it to making everything upper case (or even all lower case). Since I don't use the Mac's silly case convension in my code, one can tell if it is a Mac-defined routine or call or something of my own at a glance. This is similar to the practice some people use with Pascal: upper case for keywords, etc. Even with this constant translation nonsense, C's reduced restrictiveness (compared to Pascal) makes it a better language for serious work on the Mac. I know people who use both. I know people who use lisp too. I don't know what language is used at MicroSoft, though I'm told horror stories about it. Stephen.