Just Wondering
Jeffrey Kuskin
Why is C case-sensitive? I suppose it allows the
lexical analyzer in a C compiler to be a bit faster,
but certainly not much faster. UNIX itself is
case-sensitive, of course, but certainly C need not be.
So...why?
-- Jeff Kuskin, Dartmouth College
Blair P. Houghton
>A "I was just wondering" question:
>
> Why is C case-sensitive? I suppose it allows the
1. 26 letters and ten numbers are not enough for all the names you
use. Try looking at some old IBM 370 assembler code sometime, if
you can get around the hash-table program-naming system they forced
on programmers... (geee-yuck!)
2. Huminz iz not cumpooterz. We like it that way, and we make the
silly microchips do what WE ask. You get the same sort of thing
in a PI/grad-student relationship, too (urf!.. murfle... okay, leggo.
Sorry... forget I mentioned the PI... :)
3. Be glad it's not the whole of the APL character set. Imagine
six kinds of Oh's, and more control-keys than an emacs engine.
4. It goes along with the generality, modularity, and uninhibitionist
attitude of C. I think there's more than one way to get the entirety
of ascii into your code as parts of identifiers. I'm not the
pathologue to catalogue such things, however. (Where's Andy Koenig
when you need him? 2x:-)
5. BeCaUsE.
--Blair
"Well, that's the reason I
grew up on. You can relate,
can't you? Whaddaya mean,
this ain't Group? I been coming
here for weeks!"
Chris Torek
>
> Why is C case-sensitive?
BecAUSe peopLE arE CaSE senSITive, as YOU CAn noW see.
--
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
Domain: ch...@mimsy.umd.edu Path: uunet!mimsy!chris
Doug Gwyn
It makes programs considerably more readable, and expands the available
name space considerably.
Is there some reason C should NOT be case sensitive?
Henry Spencer
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 he...@zoo.toronto.edu
RAHUL DHESI
>Is there some reason C should NOT be case sensitive?
BACK WHEN THEY WERE THINKING ABOUT INVENTING THE FIRST KEYPUNCH, THEY
HAD AN IMPORTANT DECISION TO MAKE: SHOULD THE KEYPUNCH BE ALL
LOWERCASE OR ALL UPPERCASE? AFTER MUCH THINKING THEY SAID LETS MAKE
THEM UPPERCASE BECAUSE THEIR SO MUCH EASIER TO REED.
I THINK THIS WAS A WISE DECISION. EVEN MICROSOFT AGREES WITH ME
BECAUSE WHEN I BOUGHT MICROSOFT FORTRAN FOR MY TRS-80 IT SAID WE
RECOMMEND USE UPPERCASE BECAUSE IT'S EASIER TO REED. ALSO THE COMPILER
WAS SMART ENOUGH TO CHANGE ALL LOWERCASE TO UPPERCASE IN LISTINGS IN
CASE THE PROGRAMMER FORGOT. BESIDES STANDARD FORTRAN SAYS YOU BETTER
NOT USE LOWERCASE BECAUSE IT ISN'T IN THE STANDARD, AND ADA SAYS YOU
BETTER NOT DO THE SAME THING EITHER.
SO CONCLUSION I THINK LOWERCASE IS NOT GOOD. THAT'S WHY IT'S CALLED C
(IN UPPERCASE), BESIDES AT&T AGREES WITH ME THAT IT'S "UNIX" IN
UPPERCASE.
--
RAHUL DHESI <R.D...@BSU-CS.BSU.EDU>
UUCP: ...!{IUVAX,PUR-EE}!BSU-CS!R.DHESI
Eric A. Raymond
>> Why is C case-sensitive?
>It makes programs considerably more readable, and expands the available
>name space considerably.
I think you confuse the ability to use both upper and lower case and
the concpet of whether or not upper case characters are unique from
lower case. (Translation: You can use upper and lower case in a
non-case sensitive language. Hence by your metric, they are both
readable.)
>Is there some reason C should NOT be case sensitive?
I agree that they improve your namespace, but not in any usable way.
(Sort of like the big gear/little gear combinations on a bike. You
can use them, but it's not a good idea.) Although its debatable, I
feel its bad style to use the same name (in diffrent cases) for
different purposes within a program.
Sure, I like to put my constants (i.e. #defines) in all uppers and
variables in lowers, and stuff like that. This does not mean that
I'll use "CONFUSING" and "confusing" within a program. I will use
"CLEAR" and "coherent" within a program.
To a certain extent, programming is an art of juggling many details.
By having "QwErtyuioP" and "qWertyIOp" be the same object, I avoid
having to remember this non-semantic detail. (Of course this only
affects me when I use opc (other people's code).)
--
Eric A. Raymond (ray...@ptolemy.arc.nasa.gov)
G7 C7 G7 G#7 G7 G+13 C7 GM7 Am7 Bm7 Bd7 Am7 C7 Do13 G7 C7 G7 D+13: Elmore James
Jim Giles
> In article <13...@dartvax.Dartmouth.EDU> jsku...@eleazar.dartmouth.edu (Jeffrey Kuskin) writes:
>>A "I was just wondering" question:
>> Why is C case-sensitive? I suppose it allows the
> 2. Huminz iz not cumpooterz. We like it that way, and we make the
But, I _don't_ like it that way. Ask any literate human whether "Tree"
means something different than "tree" and you'll find out that most humans
aren't case sensitive most of the time.
> 5. BeCaUsE.
Most people would find this just plain annoying.
.
.
Jim Giles
> In article <13...@dartvax.Dartmouth.EDU> jsku...@eleazar.dartmouth.edu
> (Jeffrey Kuskin) writes:
>> Why is C case-sensitive?
> BecAUSe peopLE arE CaSE senSITive, as YOU CAn noW see.
Ah, but do you intend to imply that "BecAUSe peopLE arE CaSE senSITive,
as YOU CAn noW see" has a different _MEANING_ from "Because people are
case sensitive, as you can now see?" The fact is that most people are
_NOT_ case sensitive with respect to the _MEANINGS_ of the words. So,
computer languages probably shouldn't let case effect the meaning either.
Dave Jones
> In article <13...@dartvax.Dartmouth.EDU> jsku...@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.
SuperUser
> A "I was just wondering" question:
> Why is C case-sensitive? I suppose it allows the
> lexical analyzer in a C compiler to be a bit faster,
> but certainly not much faster. UNIX itself is
> case-sensitive, of course, but certainly C need not be.
An "I just can't help myself" answer:
This question comes from the place where [A-Z], [A-Z][0-9] was the state of
the art in variable naming schemes... (plus, of course, an optional $ to
indicate a STRING variable)
--
John Woods, Charles River Data Systems, Framingham MA, (508) 626-1101
...!decvax!frog!john, jo...@frog.UUCP, ...!mit-eddie!jfw, j...@eddie.mit.edu
Rahul Dhesi
should be a newsgroup dedicated to controversial issues of interest to
everybody in the computer-related fields. Perhaps it could be called
comp.tech-issues. Then when a flame war is about to begin, people can
redirect it to comp.tech-issues.)
The issue here is whether C ought to be case-sensitive. Italicized
words are here enclosed in vertical bars in my discussion.
In article <12...@lanl.gov> j...@lanl.gov (Jim Giles) writes:
>Ah, but do you intend to imply that "BecAUSe peopLE arE CaSE senSITive,
>as YOU CAn noW see" has a different _MEANING_ from "Because people are
>case sensitive, as you can now see?" The fact is that most people are
>_NOT_ case sensitive with respect to the _MEANINGS_ of the words.
Let's look at the pros and cons.
Why a language should not be case-sensitive:
o People use |COUNT| and |count| to mean the same thing, so the compiler
ought to do the same.
o People will often declare SendChar and later type Sendchar, and it's
painful to have to fix the error messages that a case-sensitive
compiler will generate.
Why languages should be case-sensitive:
o People may use |COUNT| and |count| to mean the same thing, but
mathematicians don't. In mathematical expressions it's very useful
to use case distinctions for related entities. For example,
Consider a graph G(V,E)
for each vertex v in V do
find an edge e in E such that e is incident on v
...
Since programming languages are meant for use by technical people,
and since computer programming and mathematics are so intimately
related, it pays to let computer programmers use the same tools
that mathematicians do. Not only should programming languages be
case-sensitive, but they should allow the use of subscripts,
superscripts, and Greek letters too, to make the notation more
powerful and more intuitive. Right now we have to go through some
trouble to compact mathematical notation to a verbose format just
because the computer's character set is so inadequate.
o If I declare |COUNT| and |SendChar| but use |count| and |Sendchar|
later, there is a good possibility that I did so in error. After
all, if I said |COUNT|, it was for a reason (why else would I have
gone to the trouble of pressing my shift key?). So if I say
|count| or |Sendchar| later the compiler ought to point out the
discrepency.
So what's the ideal compromise?
1. Keep languages case-sensitive.
2. Declare and use identifiers the same way everywhere, and don't
use both xY and Xy to refer to the same identifier.
3. (Here's the new idea) Change the compiler (or lint) to accept
an optional switch that will warn you any time you declare two
identifiers that match except for case. This will help you avoid
having both x and X in the same program if you *want* to avoid
this, but it won't prevent you from using a mathematical
convention that deliberately uses case to denote a similarity.
--
Rahul Dhesi <dh...@bsu-cs.bsu.edu>
UUCP: ...!{iuvax,pur-ee}!bsu-cs!dhesi
RAMontante
-
-... 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 Torek
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.
John Cowan
>as YOU CAn noW see" has a different _MEANING_ from "Because people are
>case sensitive, as you can now see?" The fact is that most people are
>_NOT_ case sensitive with respect to the _MEANINGS_ of the words. So,
>computer languages probably shouldn't let case effect the meaning either.
Well, sometimes. DEC is a computer company, but "Dec" is an abbreviation
for December (credit: >Programming Pearls<); "Polish" and "polish" are
actually pronounced differently, as well as having different meanings
(credit: The Black Widowers);
"Billy" and "BillY" are probably distinct e-mail names.
NASA would look pretty odd as nasa, too. My personal feeling, for what
it's worth, is that ALL UPPER CASE words should be distinct from all-lower-
case words and MiXeD-CaSE-wORDs. In this scheme "foo" and "Foo" and "FoO"
mean "foo", but "FOO" means "FOO" and is distinct from the others.
Doug Gwyn
-In article <10...@smoke.BRL.MIL> gw...@brl.arpa (Doug Gwyn) writes:
->> Why is C case-sensitive?
->It makes programs considerably more readable, and expands the available
->name space considerably.
-I think you confuse the ability to use both upper and lower case and
-the concpet of whether or not upper case characters are unique from
-lower case. (Translation: You can use upper and lower case in a
-non-case sensitive language. Hence by your metric, they are both
-readable.)
No, not having different cases map onto the same object DOES make
the code more readable. Otherwise you would have to constantly be
mentally mapping what you were reading into monocase, in effect.
Doug Gwyn
>means something different than "tree" and you'll find out that most humans
>aren't case sensitive most of the time.
You might have trouble finding literate humans these days.
Is "Pooh" different from "pooh"? Silly bear.
Doug Gwyn
>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".
Rob Carriere
>Ah, but do you intend to imply that "BecAUSe peopLE arE CaSE senSITive,
>as YOU CAn noW see" has a different _MEANING_ from "Because people are
>case sensitive, as you can now see?" The fact is that most people are
>_NOT_ case sensitive with respect to the _MEANINGS_ of the words. So,
>computer languages probably shouldn't let case effect the meaning either.
Can I give you an arbitrary math text (linear analysis will do just
fine) with all the formulas lowercased and then watch and cackle
hideously while you try to parse it? Same deal for just about any
physics/engineering/etc text. I *like* it that my float **A and
float *a are two different objects (and no, neither I nor anybody else
who knows enough to make sense of the algorithm is in the slightest
danger of confusion here -- it's all a matter of what you've been
trained to cue on).
And from the other side of the bistable multivibrator, since there are
people who like this idea, since people who don't can just not use it,
and since C has a spirit of live and let live, why should it not be
case sensitive? Is it hurting you?
SR
T. William Wells
: 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!bill
Larry Campbell
- Why is C case-sensitive?
Why not?
--
Larry Campbell The Boston Software Works, Inc.
camp...@bsw.com 120 Fulton Street
wjh12!redsox!campbell Boston, MA 02146
John Woods
> From article <17...@mimsy.UUCP>, by ch...@mimsy.UUCP (Chris Torek):
> > In article <13...@dartvax.Dartmouth.EDU> jsku...@eleazar.dartmouth.edu
> > BecAUSe peopLE arE CaSE senSITive, as YOU CAn noW see.
> _NOT_ case sensitive with respect to the _MEANINGS_ of the words.
In German, "Brocken" is a piece, a lump, a morsel. "brocken" is a verb
used as in the phrase "Brot in die Suppe brocken", meaning to break bread.
German is case sensitive. (This example is a bit contrived, especially since
"brocken" seems so limited in application. There are some less contrived
examples in German (which I could neither remember nor find in my handy
dictionary)).
Joe English
djo...@megatest.UUCP (Dave Jones) writes:
> [about the "telephone test"]
This reminds me of a question I had a while ago
but never asked anyone who would know... How does
one "pronounce" C? I know that Lisp and Forth
have certain pronunciation rules (caddr ==>
"ka-duh-derr," etc.), but are there any guidelines
for C?
Some of the rules I use are:
* is pronounced "pointer" in a declaration, "star"
in an expression;
char is pronounced "character," (as opposed to
"car" or "care;" I assume that the listener knows
how to spell it);
a[stuff] is "a sub-stuff;"
foo(a,b,c) is "foo of a comma b comma c" or just
"foo a b c" if foo is known to be a function
(I leave the punctuation implicit whenever reasonable);
!, &&, and || are pronounced "not," "and," and
"or," respectively, as are ~, &, and | except that
in the latter case I prefix the entire expression
with "bitwise," unless both logical and bitwise
operators are used in which case I write the whole
thing on a piece of paper;
void (*funtab[MAX])(int,int,char *) is pronounced
"funtab is an array, MAX long, of pointers to
function returning void, taking int, int and
character pointer."
These seem to work pretty well (assuming my
audience also speaks C) for all but really
complicated expressions.
What do other people do? In particular, what is
the real name of this -> thing? How does one
pronounce highly abbreviated standard library
functions? (To read strrchr like it's spelled
sounds like you're clearing your throat...) Is
malloc "em-allock" or "mallock?" (I prefer the
latter) and is fprintf "eff-prinf-eff" or
"phprintph?" (I prefer the former, to avoid
sounding like a Don Martin sound effect...)
Or is this a stupid question?
--Joe English
Norman Diamond
>> Why is C case-sensitive? ...
In article <1989Apr21....@utzoo.uucp> he...@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 he...@zoo.toronto.edu
Canada, 0 tries.
Norman Diamond, Sony Computer Science Lab (diamond%csl.s...@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?
Jeff Erickson
star star arg-vee. Open brace. Int eye. For eye equal one, eye less than
arg-see, eye plus plus. Print-eff quote argument percent dee is percent ess
period backslash enn endquote comma eye comma arg-vee sub eye. Close brace."
--
Jeff Erickson Claris Corporation | Birdie, birdie, in the sky,
408/987-7309 Applelink: Erickson4 | Why'd you do that in my eye?
kr...@claris.com ames!claris!krazy | I won't fret, and I won't cry.
"I'm a heppy, heppy ket!" | I'm just glad that cows don't fly.
Tom Stockfisch
>>> Why is C case-sensitive?
>>It makes programs considerably more readable, and expands the available
>>name space considerably.
>I agree that they improve your namespace, but not in any usable way.
>(Sort of like the big gear/little gear combinations on a bike. You
>can use them, but it's not a good idea.) Although its debatable, I
>feel its bad style to use the same name (in diffrent cases) for
>different purposes within a program.
I try to avoid it, but I succumbed to temptation after reading C++ code.
In C++ a struct tag name is also used as the name of a constructor for
that struct. In C I always use upper case for types and (mostly) lower
case for functions. I used to use lower case for types until I ran into
a pcc bug in which inner-scope auto variable names collide with typedef
names. Anyway, I now use the lower case version of a struct name as the
name of the constructor of the struct. e.g.,
typedef struct NODE {
char *name;
struct NODE *lchild;
struct NODE *rchild;
} NODE;
NODE *
node(name)
char *name;
{
NODE *result = malloc( sizeof(NODE) );
result->name = strsave(name);
result->lchild =
result->rchild = NULL;
return result;
}
Note that I overload NODE as the structure tag and typedef name. This
also is similar to the way C++ does things.
--
|| Tom Stockfisch, UCSD Chemistry t...@chem.ucsd.edu
S. Manoharan
Bill ({ uunet | novavax } !twwells!bill) writes:
>In article <17...@mimsy.UUCP> ch...@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: s...@uk.ac.ed.lfcs Dept of Computer Science
Uucp : ..!mcvax!ukc!lfcs!sam University of Edinburgh
Arpa : sam%lfcs.e...@nss.cs.ucl.ac.uk Edinburgh EH9 3JZ UK.
Peter da Silva
> I agree that they improve your namespace, but not in any usable way.
> (Sort of like the big gear/little gear combinations on a bike. You
> can use them, but it's not a good idea.) Although its debatable, I
> feel its bad style to use the same name (in diffrent cases) for
> different purposes within a program.
You mean this is evil and rude:
BOOL framistan(file)
char *file;
{
FILE *fp;
if(!(fp = fopen(file, "r")))
return FALSE;
...
How about this:
#define Strlen(s) (s?strlen(s):0)
How about this:
: LOOP
?COMPILE
3 ?MATCH
COMPILE loop HERE - HERE ! ;
IMMEDIATE
How about homonyms?
BOOL boule(fyle)
char *fyle;
{
FILE *fp;
if(!(fp = fopen(fyle, "r")))
return FALSE;
...
--
Peter da Silva, Xenix Support, Ferranti International Controls Corporation.
Business: uunet.uu.net!ficc!peter, pe...@ficc.uu.net, +1 713 274 5180.
Personal: ...!texbell!sugar!peter, pe...@sugar.hackercorp.com.
Peter da Silva
> means something different than "tree" and you'll find out that most humans
> aren't case sensitive most of the time.
How about Nice and nice?
Tim_CDC...@cup.portal.com
>>> Why is C case-sensitive?
>> BecAUSe peopLE arE CaSE senSITive, as YOU CAn noW see.
> the _MEANINGS_ of the words. So,
i was reading a book recently which covered this topic from a linguistics
point of view. the book rhetorically asked if the reader could come up with
any reason why the first letter of a sentence should be capitalized.
when one comes right down to it, there is no good reason; you already have
the period to visually terminate the previous sentence.
so let's establish a new standard right now. from this point forward,
the only allowable usage of capital letters shall be for EMPHASIS. this
will permit emphasis to be rendered on devices which do not support
underlining. once underlining is universally supporte on all media and
all devices, we can eliminate capital letters altogether, and think of
something else to do with 26 entries in the ascii table (smiley faces?).
:-)
Tim_CDC...@cup.portal.com | Control Data...
...!sun!portal!cup.portal.com!tim_cdc_roberts | ...or it will control you.
Kevin Franden
>"Pound include st'deeoh dot aitch. Main arg-see arg-vee. Int arg-see. Care
>star star arg-vee. Open brace. Int eye. For eye equal one, eye less than
paren _should_ be here
(notice the case sensitivity=-)
>arg-see, eye plus plus. Print-eff quote argument percent dee is percent ess
^
paren here too? (or are you doing a one liner?)
>period backslash enn endquote comma eye comma arg-vee sub eye. Close brace."
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Kevin Franden UUCP: {backbone}!pyramid!infmx!kevinf
Informix Software Inc
disclaimer("I said what I said and not my employer");
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Jim Giles
> the code more readable. Otherwise you would have to constantly be
> mentally mapping what you were reading into monocase, in effect.
Most people DO mentally mapp int monocase when reading. Otherwise,
I would haver to conclude that the word "DOES" is your statement is
intended to mean something other than "does". In fact these are
perfect examples of why a programming language should NOT be case
sensitive. It allows better code readibility by allowing the programmer
to EMPHASIZE parts of the code.
Henry Spencer
>I can't recall EVER wanting to communicate a program to someone orally,
It can happen, but it's exceedingly rare. I once wrote an archive unpacker
whose major virtue was that it was short enough to be read over the phone
to my girlfriend's customers. (Why? Back then, not all commercial suppliers
had upgraded their software to use V7 archive format -- some were still using
the old V6 one -- and this meant that some sites had trouble with distribution
tapes containing V7 archives.)
Talking about a fragment of a program over the phone is not uncommon. But
then capitalization is seldom an issue.
--
Jim Giles
> And from the other side of the bistable multivibrator, since there are
> people who like this idea, since people who don't can just not use it,
> and since C has a spirit of live and let live, why should it not be
> case sensitive? Is it hurting you?
It hurts me in two ways:
1) My job often requires me to work-on, debug, or rewrite other people's
code. If the other person distinguishes "myvar" from "myVar" and
several similar cases, this causes considerable heartburn.
2) Since C distinguishes case, I can't use it to help the readability
of code by EMPHASIZING parts that I consider important.
Fortunately, for both these cases, C has yet to become a really common
language in the big computer environment. Even UNIX based supers mostly
use Fortran-like languages for production.
Jim Giles
> [...]
> o People may use |COUNT| and |count| to mean the same thing, but
> mathematicians don't. In mathematical expressions it's very useful
> to use case distinctions for related entities. For example,
> Consider a graph G(V,E)
> for each vertex v in V do
> find an edge e in E such that e is incident on v
> ...
Math texts also tend to use one character identifiers for all objects
under consideration. I don't suppose you also recommend limiting
identifiers to one character?!? Programming is a fundamentally different
process from writing math texts. There is no a_priori reason for one
to resemble the other. Indeed, I have argued before that the syntax
and semantics of arithmetical operators in programming languages _should_
resemble those use in standard math as much as possible. However, I
come down on the opposite side of the issue on case sensitivity. My
opinion: use multicharacter identifiers and _don't_ distinguish case.
So in a programming language:
type vertex... ! type - what you just called "V"
vertex:: v1,v2,... !variables of type vertex
> So what's the ideal compromise?
>
> 1. Keep languages case-sensitive.
-- better yet, make case sensitivity optional.
> [...]
> 3. (Here's the new idea) Change the compiler (or lint) to accept
> an optional switch that will warn you any time you declare two
> identifiers that match except for case. This will help you avoid
> having both x and X in the same program if you *want* to avoid
> this, but it won't prevent you from using a mathematical
> convention that deliberately uses case to denote a similarity.
Better yet, make declaration of identifiers which differ only in case
strictly illegal. Well, I guess it HAS to be just a warning for C
to be backward compatible. Still -- a NEW language could avoid these
mistakes.
One last point. I have a color computer a home. To me, having a
case sensitive language is as bad as having a _color_ sensitive one.
Can you imagine?!? Consider a program with 512 different variables,
all spelled "a". How would _YOU_ like to try to debug such a monster?
Barry Margolin
followups to comp.lang.misc.
In article <10...@socslgw.csl.sony.JUNET> dia...@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.
bar...@think.com
{uunet,harvard}!think!barmar
Blair P. Houghton
>From article <26...@buengc.BU.EDU>, by b...@buengc.BU.EDU (Blair P. Houghton):>> 2. Huminz iz not cumpooterz. We like it that way, and we make the
>> silly microchips do what WE ask. [...]
>But, I _don't_ like it that way. Ask any literate human whether "Tree"
>means something different than "tree" and you'll find out that most humans
>aren't case sensitive most of the time.
Suggestion:
alias cc to run your source through 'tr [a-z] [A-Z]' then feed it
to '/bin/cc'. _You_ can decide what to do about options and the
ordering thereof.
--Blair
"Besides, in all of my programs
I always have variables named
If, foR, and siZeof... :-)"
David Goodenough
> Mars in 1980s: USSR, 2 tries,
Funny - I thought the score was:
Tries Successes
USA 2 2
Didn't they get two probes to land on the surface????
[BTW that is meant to be "they". I, like Mr. Spencer, am Canadian]
--
d...@lakart.UUCP - David Goodenough +---+
IHS | +-+-+
....... !harvard!xait!lakart!dg +-+-+ |
AKA: dg%lakar...@xait.xerox.com +---+
David Dyer-Bennet
:> Why is C case-sensitive?
:
:It makes programs considerably more readable, and expands the available
:name space considerably.
:Is there some reason C should NOT be case sensitive?
Well, I've seen quite a few bugs that were finally determined to be caused
by programmers looking at code with identifiers with the same spelling but
different casing, and thinking they were the same. I've found I got over
that MOST of the time, and remember to check for it the rest of the time;
but it means that when "thinking c" I have to think differently than when
I'm doing most other reading tasks, which makes things epsilon much harder.
It also enforces rules about casing of identifiers, so the same identifier
ALWAYS looks the same, which is clearly good.
How DO people feel about identifiers differing only in casing? Is this
ok? To be COMPLETELY avoided? To be avoided except in a very few
well-understood conventional cases?
--
David Dyer-Bennet, d...@terrabit.fidonet.org, or d...@ns.network.com
or d...@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
David Dyer-Bennet
:In article <13...@dartvax.Dartmouth.EDU> jsku...@eleazar.dartmouth.edu
:(Jeffrey Kuskin) writes:
:>
:> Why is C case-sensitive?
:
:BecAUSe peopLE arE CaSE senSITive, as YOU CAn noW see.
It's not so clear to me (though that's certainly a cogent example). I
recognize the word "It's" at the beginning of my first sentence as
just the same as the word "it's" in the middle of some sentence
somewhere without any problem (after 12 years or so of concentrated
training in school, that is).
I think people are pretty thoroughly trained to NOT be case sensitive
at the individual word level, and that your example is hard to read
because it violates our training to use casing as part of punctuation.
Making the rules of c casing in conflict with the rules of English
casing (which I percieve them to be) was probably a bad idea, unless
there are large benefits somewhere. I've certainly seen a lot of
"casing" bugs.
David Dyer-Bennet
:the code more readable. Otherwise you would have to constantly be
:mentally mapping what you were reading into monocase, in effect.
Which we've been trained to do by 12 years or so of schooling. I still
think it's a bad idea to fight it.
TA7
>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
David Dyer-Bennet
:Well, sometimes. DEC is a computer company, but "Dec" is an abbreviation
:for December (credit: >Programming Pearls<);
I see Dec and dec for the computer company all the time. And I generally
use and often see DEC for the month. The context provides more clues than
the casing does.
:"Billy" and "BillY" are probably distinct e-mail names.
Probably, but this is outside the range of normal English usage and back
into computer conventions.
:NASA would look pretty odd as nasa, too.
I see the lower-case version on the net all the time, and it's never confused
me or even slowed me down. In this case, there isn't another common term
that differs only in the formally-correct casing, so there's no ambiguity
to resolve.
I continue to believe that a trained English reader is essentially a
monocase device. The casing rules that exist mostly don't serve to
disambiguate otherwise identical terms, and when they do they are mostly
not followed; yet people can read the stuff anyway.
David Dyer-Bennet
:And from the other side of the bistable multivibrator, since there are
:people who like this idea, since people who don't can just not use it,
:and since C has a spirit of live and let live, why should it not be
:case sensitive? Is it hurting you?
Just a reminder -- for portable code, externals should still be limited
to 6 characters monocase.
Wayne A. Christopher
> case sensitive language is as bad as having a _color_ sensitive one.
> Can you imagine?!? Consider a program with 512 different variables,
> all spelled "a". How would _YOU_ like to try to debug such a monster?
That's like an idea a friend of mine had -- scratch 'n' sniff math texts.
We have 5 senses, so why not maximize the bandwidth of the human-computer
interface? You could have variables like { picture of a green cow, rotten
egg smell, church bell, pinprick from the keyboard }.
Wayne
David Dyer-Bennet
:In article <13...@dartvax.Dartmouth.EDU> jsku...@eleazar.dartmouth.edu (Jeffrey Kuskin) 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?
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.
Pete Holsberg
--
Pete Holsberg UUCP: {...!rutgers!}princeton!mccc!pjh
Mercer College CompuServe: 70240,334
1200 Old Trenton Road GEnie: PJHOLSBERG
Trenton, NJ 08690 Voice: 1-609-586-4800
Dave Jones
...
>
> 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.
Peter Desnoyers
>
> type vertex... ! type - what you just called "V"
> vertex:: v1,v2,... !variables of type vertex
Actually, what he said was
set V of vertex
for v = set$element in V
...
Peter Desnoyers
Dave Jones
> In article <44...@goofy.megatest.UUCP> djo...@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
Dave Jones
>
> information about the identifier that are not properly conveyed by the
> name. Here's my table:
>
> 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
Dave Jones
>
> djo...@megatest.UUCP (Dave Jones) writes:
>
>> [about the "telephone test"]
>
> This reminds me of a question I had a while ago
> but never asked anyone who would know... How does
> one "pronounce" C?
...
> Some of the rules I use are:
...
> char is pronounced "character," (as opposed to
> "car" or "care;" I assume that the listener knows
> how to spell it);
On the East Coast, it is pronounced "care". Here in Silicon Valley, it
is pronounced "char".
...
> ... is this a stupid question?
Not at all. Having had quite a bit of experience recently discussing
programs and proposed programs, both over the phone and in person,
with persons from the other coast, it would seem advantageous to have
some conventions.
It would also seem like a dandy topic of personal preference and opinion
which could provoke an amusing religious war here on the net.
We'll see what happens.
Rob Carriere
r...@raksha.eng.ohio-state.edu (Rob Carriere):
>> And from the other side of the bistable multivibrator, since there are
>> people who like this idea, since people who don't can just not use it,
>> and since C has a spirit of live and let live, why should it not be
>> case sensitive? Is it hurting you?
>It hurts me in two ways:
>1) My job often requires me to work-on, debug, or rewrite other people's
> code. If the other person distinguishes "myvar" from "myVar" and
> several similar cases, this causes considerable heartburn.
This is not an argument, you might as well argue that your beloved
FORTRAN is at fault for letting people name their REALs a0, a1,
a2 etc in order of occurence, and INTEGERs i0, i1, etc. Any
reasonable namespace can be abused by inappropriate choices. Your
argument would work only if you could show that *all* case-sensitive
choices of variable names are bad, and we've already seen several
counterexamples to that.
>2) Since C distinguishes case, I can't use it to help the readability
> of code by EMPHASIZING parts that I consider important.
/* VVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVV */
foo[37]->bar.baz += 3*pi/(2.05*e/c); /* this here be IMPORTANT! */
/* ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ */
SR
"I never mildly exaggerate."
Rob Carriere
>identifiers to one character?!?
Limiting, never. Allowing, certainly.
exp( j*2*rhat(i)*wc ) .* ( jw.^that(i) ) % this is not C, but it gets the
% point across.
exp( Square_root_of_minus_one*2*Estimated_relative_range(scatterer_index) ..
*vector_of_measurement_frequencies_divided_by_lightspeed ) ..
* ( vector_of_measurement_frequencies_multiplied_by_the_square_root_of_minus_one ..
.^ estimated_scatterer_type( scatterer_index ) )
There *is* a reason most mathematicians prefer algebra over English
desciptions.
> Programming is a fundamentally different
>process from writing math texts. There is no a_priori reason for one
>to resemble the other.
Quite. But if I'm programming from a math text, I'd rather be allowed
to stick as closely as possible to that text's notation. I already
find rhat for r-with-^ annoying; I'll positively start screaming if I
have to rename half my variables to conform to someone's empty idea of
a namespace.
>> 1. Keep languages case-sensitive.
> -- better yet, make case sensitivity optional.
That, I'd happily go along with.
>Better yet, make declaration of identifiers which differ only in case
>strictly illegal. Well, I guess it HAS to be just a warning for C
>to be backward compatible. Still -- a NEW language could avoid these
>mistakes.
But, it is not a mistake. At least not to quite a number of people.
>One last point. I have a color computer a home. To me, having a
>case sensitive language is as bad as having a _color_ sensitive one.
>Can you imagine?!? Consider a program with 512 different variables,
>all spelled "a". How would _YOU_ like to try to debug such a monster?
I wouldn't like to have 512 variables of any ilk in consideration
scope in any way, regardless of naming schemes. Me got only small
skull, me KISSes all my programs (when they let me :-). I *have*
debugged mathematical arguments where there were variables r, R, rho
and GAMMA (looks like a rho), all blissfully different. I was happy
with it. There was a system to the choice of alphabets, and same
letter in different alphabets meant related quantities; it was all
very intuitive.
SR
King Su
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-...@vlsi.caltech.edu Caltech Corp of Cosmic Engineers |
\*------------------------------------------------------------------------*/
Anthony Scian
>Better yet, make declaration of identifiers which differ only in case
>strictly illegal. Well, I guess it HAS to be just a warning for C
>to be backward compatible. Still -- a NEW language could avoid these
>mistakes.
Given a case-sensitive compiler, you can program to your heart's
content in case-insenstive bliss, so what is the problem?
Just pipe your source through 'tr' and map the entire alphabet
to whatever case you like. (If you are feeling ambitious, write your
own CPP so that there is one less filter in the pipeline)
As for keywords, what is wrong with:
#define IF if
#define WHILE while
etc.
If you dictated that case-insensitivity rules, those of us
that want case-sensitive compilers would be out of luck.
I find it really annoying when I find case errors later rather
than sooner because of case-insensitive tools.
As for the `silly errors' point, we don't need more relaxation
of checking when it comes to errors. We have enough lazy C
trash to rid ourselves of (what? default int, default export, etc).
I think you lost the important point in this thread of thought:
Programmers should not overload names with case-sensitive variations
on a theme.
//// Anthony Scian afs...@violet.uwaterloo.ca afs...@violet.waterloo.edu ////
"I can't believe the news today, I can't close my eyes and make it go away" -U2
Stephen J. Friedl
>Mars in 1980s: USSR, 2 tries, | Henry Spencer at U of Toronto Zoology
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 / fri...@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
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 do...@inmet.inmet.com uunet!inmet!dokos
Carrick Talmadge
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: c...@physics.purdue.edu
USENET: ...!pur-ee!pur-phy!clt
BITNET: talm...@purccvm.bitnet
Rahul Dhesi
>under consideration. I don't suppose you also recommend limiting
>identifiers to one character?!?
There *is* a reason for mathematicians to use single-character
identifiers. This is because a large fraction of mathematical
expressions contain some type of product, and it's very convenient to
be able to say "abc" and mean "a * b * c".
Once you begin with the convention that abc is a product of three
terms, it's confusing to do otherwise in the same book or journal.
Most computer programs do not necessarily involve products, so it pays
to give up the convenience of mathematical notation to gain clarity by
using longer identifiers. But single-character identifiers *are*
useful. Most loop counters are one-char identifiers. When you are
evaluating a conventional mathematical expression it often pays
stick to that format.
--
Rahul Dhesi <dh...@bsu-cs.bsu.edu>
UUCP: ...!{iuvax,pur-ee}!bsu-cs!dhesi
Rob Carriere
>I continue to believe that a trained English reader is essentially a
>monocase device. The casing rules that exist mostly don't serve to
>disambiguate otherwise identical terms, and when they do they are mostly
>not followed; yet people can read the stuff anyway.
English != C
A trained English reader does not a trained C programmer make, nor
vice versa.
SR
Doug Gwyn
Where that's true, for example perhaps LANL, I'm sure it's not because
C identifiers support case distinction. It is much more likely an
inertial effect. At BRL, many of the important applications that run
on our Crays are written in C.
Jeff Erickson
> In article <99...@claris.com> I write:
>>"Pound include st'deeoh dot aitch. Main arg-see arg-vee. Int arg-see. Care
>>star star arg-vee. Open brace. Int eye. For eye equal one, eye less than
> ^
> paren _should_ be here
> (notice the case sensitivity=-)
>>arg-see, eye plus plus. Print-eff quote argument percent dee is percent ess
> ^
> paren here too? (or are you doing a one liner?)
>>period backslash enn endquote comma eye comma arg-vee sub eye. Close brace."
Nope. No parens. I'm making the assumption that the listener knows the
language. Notice I also left out every semicolon and all the other parens,
as well as the angle brackets around "st'deeoh dot aitch".
C'mon. You know the laguage well enough to have figured out that parens
should go there. Why should I have to remind you?
If I had been doing a one-liner, I would have explicitly stated "eye plus
plus COMMA print-eff..." to make sure you knew. And I probably would've
said the parens, too.
--
Jeff Erickson Claris Corporation | Birdie, birdie, in the sky,
408/987-7309 Applelink: Erickson4 | Why'd you do that in my eye?
kr...@claris.com ames!claris!krazy | I won't fret, and I won't cry.
"I'm a heppy, heppy ket!" | I'm just glad that cows don't fly.
Jeff Erickson
> One last point. I have a color computer a home. To me, having a
> case sensitive language is as bad as having a _color_ sensitive one.
> Can you imagine?!? Consider a program with 512 different variables,
> all spelled "a". How would _YOU_ like to try to debug such a monster?
I've talked to a couple of friends of mine about this. I have a color
computer, too. I DEFINITELY DO NOT WANT COLOR SENSITIVE COMPILERS! Let
me get that out of the way right of the bat!
What I would like is the ability to change text styles, sizes, colors, and
fonts within my code. I could, for example, have all my comments in a smaller
point size than my code. Or I could make critical sections of code red.
The code itself would still be just the text, and it would be trivial to
return the code to its original monofont status, but the addition of
optional style changes ould make some things really easy.
One of my firends wants a comment font, so you don't need comment delimiters,
but I think that's going a bit too far.
I know, I know. It's silly. But it would be damn useful. To me anyway.
Comments??
James C. Benz
>language in the big computer environment.
Geez, where you been for the last ten years, Rip Van?
--
Jim Benz jcb...@unix.cis.pittsburgh.edu If a modem
University of Pittsburgh answers,
UCIR (412) 648-5930 hang up!
David Geary
S. Manoharan writes:
Bill ({ uunet | novavax } !twwells!bill) writes:
::: In article <17...@mimsy.UUCP> ch...@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" ~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Chris (Batches? We don't need no steenking batches!) Seaman
<
< >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?
<
< 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-
< silly to permit two distinct identifiers to differ only in case.
<
<
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
c...@cpsc6a.att.com <or> | || See "Attack of the Killer Smiley"!
..!ihnp4!cpsc6a!crs | \vvvvvv/ Coming Soon to a newsgroup near you!
| \____/
Jim Giles
> set V of vertex
> for v = set$element in V
> ...
In that case, it _should_ have been:
set vertex_set of vertex
for a_vertex = set$element in vertex_set
Assuming that the two statements above may be separated in the program
by many lines (even pages) of other code, the "vertex_set" variable is
_MUCH_ easier to read, maintain, and even to _WRITE_!
Karl Heuer
>How does one "pronounce" C?
Oh God, not this thread again.
This is pretty much a religious issue. Some people pronounce "char" like the
English word with the same spelling; others pronounce it like the first
syllable of "character". (And whether the latter is the same as "care"
depends on your dialect.) People will argue for one or the other on grounds
of consistency, but it turns out that nobody uses a fully consistent style
anyway. Next we start to discuss the correct pronunciation of symbols like
`#' (sharp, pound, number, hash, mesh, grid, octothorp, tictactoeboard, etc.),
common phrases like "bash bang splat", and then someone will post the complete
list from The Hacker's Dictionary, including the Intercal names like "angle
worm" for "<-".
If we must go through this, let's keep it to comp.misc, okay?
Karl W. Z. Heuer (ima!haddock!karl or ka...@haddock.isc.com), The Walking Lint
Jeff Hardy
case sensitivity is HARD. I believe that HARD is like BEAUTY and is in the
eye of the beholder. What is HARD for you MAY be EASY for me and what is
HARD for me MAY be EASY for you. I don't believe that Dennis designed
C to be HARD. I don't believe that HARDness is an attribute of the language
at all. Many people have brought out the useful fact that case sensistivity
allows another means of conveying information. Why preclude that means
simply because to some it is HARD. I dare say that if we prevented early on
anything that is HARD, we wouldn't be where we are today. What we DO need
however is the recognition that to some it is indeed HARD and as others
have brought out it is our responsibility to try not to be arbitrarily
HARD on others. Clear documentation should help in some degree. Perhaps
well understood conventions will help also.
Also, I do not necessarily map UPPERCASE to lowercase in order to understand
some word. I believe that my thought processes are more mature than that.
I also do not move my lips when I read. People who learn more than one
language learn to think in the other languages too. They do not have to
translate into their mother tongue to understand what is being said. I'm sure
this can be appliled to programming languages as well. The mental
translation and HARDness pass away with experience and growth. To deny
ourselves the HARDness is to deny our capacity for growth.
Jeesh, I'm really sorry for the sermon :-), but this did seem to border on
the religious.
Cheers,
Jeff Hardy
T. William Wells
In article <12...@lanl.gov> j...@lanl.gov (Jim Giles) writes:
: Most people DO mentally mapp int monocase when reading. Otherwise,
: I would haver to conclude that the word "DOES" is your statement is
: intended to mean something other than "does". In fact these are
: perfect examples of why a programming language should NOT be case
: sensitive. It allows better code readibility by allowing the programmer
: to EMPHASIZE parts of the code.
Inconsistent casing Makes the Code harder to Read. Consistent casing
is better, pretty much independetly of which style of case you use.
And if you use consistent casing, you want your compiler system to
tell you when you've goofed.
So, even if you want to use case for such purposes as emphasis, you
want case sensitivity in the language.
---
Bill { uunet | novavax } !twwells!bill
Tainter
>1) My job often requires me to work-on, debug, or rewrite other people's
> code. If the other person distinguishes "myvar" from "myVar" and
> several similar cases, this causes considerable heartburn.
There is one more options. Design it into the language that case
must match but that no two symbols when case ignored are allowed
to be the same. I.e. case and Case is illegal! Or add it to
your coding guidelines and run the code through a checker to
enforce it.
Any votes for this? It won't get my vote. I like using WHITE
and white as distinct, one the instantiation of the other, and
don't agree it makes code harder to read. As long a reasonable
convention is used for why they differ in case there is little problem.
Personally, I think people who do mixed case like MyVar should be shot!
I can tolerate Variable but it had better be some special class of
symbol (typedef, structure tag, class, etc.)
>
>2) Since C distinguishes case, I can't use it to help the readability
> of code by EMPHASIZING parts that I consider important.
A frightening prospect! This would force me to run all code I know
you wrote through a filter to calm it down, which would be very
messy under a change management system. What you think you
know what is important to the next guy reading the code? This type
of thing just distracts from general understanding of the code and
context.
--johnathan.a.tainter--
Tainter
>>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
Peter Desnoyers
>In that case, it _should_ have been:
>
>Assuming that the two statements above may be separated in the program
>by many lines (even pages) of other code, the "vertex_set" variable is
>_MUCH_ easier to read, maintain, and even to _WRITE_!
I don't agree. If the form in which everyone learned the equation uses
X, x, and z, then use those very same symbols. Which would you rather
read:
Area := ratio_of_diameter_to_circumference * radius_of_circle ^^2
or
___ 2
A = | | R
Peter Desnoyers
Athanasios(Tom) Zougas
> [...]
>>> 1. Keep languages case-sensitive.
>> -- better yet, make case sensitivity optional.
>
>That, I'd happily go along with.
>
Please don't make it optional. I would end up using case-sensitivity
ON just in case I did want to distinguish between MyVar and MYVAR. Or
in case someone else wanted to distinguish between TheirVar and
THEIRVAR. KnowwhatImean?
Tom.
--
This is my signature:
tom zougas
T. William Wells
: >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:
:
:
: 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.
Athanasios(Tom) Zougas
>Henry signs:
>>Mars in 1980s: USSR, 2 tries, | Henry Spencer at U of Toronto Zoology
>>2 failures; USA, 0 tries. | uunet!attcan!utzoo!henry he...@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.
John Woods
> From article <12...@lanl.gov>, by j...@lanl.gov (Jim Giles):
> > all spelled "a". How would _YOU_ like to try to debug such a monster?
> fonts within my code. I could, for example, have all my comments in a smaller
> point size than my code. Or I could make critical sections of code red.
One thing *I've* wanted is the ability include pictures in comments (for
example, imagine feeding a MacWrite file to the Macintosh C compiler).
The ability to include real drawings of box-and-pointer diagrams could
immensely clarify some hairy pieces of code now and then. Occaisionally
I have stooped to ASCII graphics, but somehow they just don't work as well.
And then again, having fonts be significant in variable names would make
it easy to have variables like "script-G" that pop up in Quantum Mechanics...
(No, I am NOT serious. :-)
--
John Woods, Charles River Data Systems, Framingham MA, (508) 626-1101
...!decvax!frog!john, jo...@frog.UUCP, ...!mit-eddie!jfw, j...@eddie.mit.edu
Jim Giles
> In article <12...@lanl.gov> j...@lanl.gov (Jim Giles) writes:
>>Fortunately, for both these cases, C has yet to become a really common
>>language in the big computer environment.
>
> Geez, where you been for the last ten years, Rip Van?
I have found that there are definitely _better_ languages in the world
than C. Some, like Fortran, are only better for certain applications.
Others are better than C in almost _every_ respect, like Modula2-3 or
even ADA. There are, of course, derivatives of C itself that are
uniformly better than C - like C++, and Objective C is better than
that but not widely available yet.
I usually don't switch to a language simply because it's trendy. That
seems to me to be the only reason to switch to C (it also seems to be
the general idea behind your: "last ten years, Rip Van?). Not even at
home on my personal computer - there I prefer SmallTalk for playing with
algorithms and Modula2 for programs which need to be small/fast. I have,
of course, used C - I even wrote an interpreter at home for it (just to
get a better feel for the language) - the more I learn about it, the less
I like it.
So, I say again: Fortunately C has yet to become a really common
language in the big computer environment - or I would be _forced_
to use it as part of my job.
Badger BA 64810
[..]
>so let's establish a new standard right now. from this point forward,
>the only allowable usage of capital letters shall be for EMPHASIS. this
>will permit emphasis to be rendered on devices which do not support
>underlining. once underlining is universally supporte on all media and
>all devices, we can eliminate capital letters altogether, and think of
>something else to do with 26 entries in the ascii table (smiley faces?).
> :-)
>Tim_CDC...@cup.portal.com | Control Data...
>...!sun!portal!cup.portal.com!tim_cdc_roberts | ...or it will control you.
In \TeX, it is considered more elegant to {\em emphasize} a concept with
a contrast between {\rm roman} and {\it italic} fonts, rather than
crudely \underline{underlining} something! (In a manuscript, underlining
is used to indicate that italics are desired.)
At the moment we are constrained by current character/terminal/printer/font
technology to define programming languages in a linear sequence of
(probably ASCII) characters. I'm not sure we're ready for the the coming
graphical/visual technology explosion.
As regards the theme, ``Why case-sensitivity?''
I _definitely_ prefer being able to use both upper and lower case,
with a predominance of lowercase.
I generally *don't* like it when an identifier is used in several different
case treatments: I read ``APart'' and ``apart'' differently, so in Ada,
would always write that as ``a_part'' and ``apart''. I wouldn't allow
mere capitalization to serve as a word marker.
Bernard A. Badger Jr. 407/984-6385 |``Use the Source, Luke!''
Secure Computer Products |``Get a LIFE!'' -- J.H. Conway
Harris GISD, Melbourne, FL 32902 |Buddy, can you paradigm?
Internet: bbadger%x1...@trantor.harris-atd.com|'s/./&&/g' Tom sed expansively.
Jim Giles
> X, x, and z, then use those very same symbols. Which would you rather
> read:
> Area := ratio_of_diameter_to_circumference * radius_of_circle ^^2
> or
> ___ 2
> A = | | R
Neither. I'd rather see:
c1.area <- @pi * c1.radius^2
This has several advantages.
1) It is possible to write with my keyboard without multi-line superscripting
or special character drawing.
2) Pi _should_ be a built-in constant in a programming language. Its value
should be kept to the maximum (machine dependent) precision, but it should
be used only to the precision required by the rest of the expression.
(I think that '@' is just as good a character as any to signal intrinsic
constants.)
3) This example identifies, completely and uniquely, _which_ circle is
having its area computed. You might argue that the data type 'circle'
should have sub-field names that are shorter (I won't argue that point).
But both your examples imply only one circle in the computational
universe of possibilities. This is the difference between forms that
you learn and forms that you _use_. The form you learn is a template
that must be filled out with specifics in actual use. Programming
is a medium of _use_, not a medium of learning. It must, therefore,
have not only the learned _form_, but be filled out with the specifics
as well.
4) It has an _assignment_ symbol. Your example is misleading in its use
of the equal sign. In a functional language, like VAL, your second
example could as easily mean that you're defining 'R' instead of your
probable intent to define 'A'. (Of course, ":=" looks nothing like
a left-arrow and should be avoided for assignment in a programming
language design.)
Joe English
j...@lanl.gov (Jim Giles) writes:
>
>2) Since C distinguishes case, I can't use it to help the readability
> of code by EMPHASIZING parts that I consider important.
I don't get it...
c = read(fd,buffer,count);
/* read stuff from file */
c = READ(fd,buffer,count);
/* be SURE to read stuff from file. Don't write or lseek, READ. */
c = read(FD,buffer,count);
/* read from file FD. Not some other file descriptor, FD. */
c = read(fd,BUFFER,count);
/* read stuff into BUFFER, and not somewhere else. */
I still don't get it.
--Joe English
Pat R. Calhoun
> But, I _don't_ like it that way. Ask any literate human whether "Tree"
> means something different than "tree" and you'll find out that most humans
> aren't case sensitive most of the time.
Then why do you use _I_ and not _i_??
--
"The statements above does not necessarily reflect the views of the
writer, the President of the United States, or the cleaning staff."
_^_ ||| Pat "King of the Trenches" Calhoun
<o o> | Technical Support Group, Lanpar Technologies
/\/\/\/\/\ UUCP: ...!attcan!nebulus!tslanpar!mslanpar
DISCLAIMER: "Read the DAMN manual, I don't need this SHIT!!"
Norman Diamond
>>>Mars in 1980s: USSR, 2 tries, | Henry Spencer at U of Toronto Zoology
>>>2 failures; USA, 0 tries. | uunet!attcan!utzoo!henry he...@zoo.toronto.edu
I added:
>> Canada, 0 tries.
In article <11...@vsi.COM> fri...@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.s...@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 Torek
appears to claim that
>>In article <17...@mimsy.UUCP> ch...@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: ch...@mimsy.umd.edu Path: uunet!mimsy!chris
Norman Diamond
> 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?
T. William Wells
: 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!)
Doug Gwyn
Congratulations.
I don't know where the utterly fantastic notion that natural language
should serve as a guide for a programming language came from. They
have different goals, different structure, different methods, and
different "clientele". Almost the only thing they have in common is
the word "language", but the only common concept in these two usages
is, essentially, "mode of expression", which is way too general to
provide detailed guidance.
If people approach programming the same way that they approach essay
writing, no wonder they have problems. But in that case it's not the
fault of the programming language.
Doug Gwyn
>What I would like is the ability to change text styles, sizes, colors, and
>fonts within my code.
Some debuggers offer this to some degree.
I've encountered (more than once) comments in C code that had to be run
through [n]eqn|[nt]roff before they were intelligible to anyone other
than a die-hard roffer. Of course if you have a decent text editor this
is a piece of cake.
Doug Gwyn
You're certainly entitled to your opinions, if you've formed them as
the result of objective consideration of the facts available to you.
However, if you don't like C, you're doing the readers of this newsgroup
a disservice by complaining about it, just as it does nobody any good
for VMS advocates to argue that UNIX is awful in the UNIX newsgroups.
Constructive suggestions about ways to work around what you perceive
to be deficiencies in C would be helpful. If it weren't too late now,
suggestions about ways to improve the language would have been useful
too. (I don't recall seeing yours in the mountain we had to wade
through before or during the public reviews of the proposed C standard.)
But if you're not trying to be helpful, then please keep quiet --
the signal-to-noise ratio of this newsgroup is low enough already.
Bjorn Engsig
>ok? To be COMPLETELY avoided? To be avoided except in a very few
>well-understood conventional cases?
>
One of the more common cases where you use identifiers only different in case
is for union fields inside structures, e.g.:
struct abc {
int a, b, c;
union {
char Array[4];
long Whole;
} wa_union;
};
#define array wa_union.Array
#define whole wa_union.Whole
which allows you to rerefence the union fields in your program without
having to supply the union name, i.e. abcvar.array[2] in stead of
abcvar.wa_union.Array[2].
--
Bjorn Engsig, ORACLE Europe \ / "Hofstadter's Law: It always takes
Path: mcvax!orcenl!bengsig X longer than you expect, even if you
Domain: ben...@oracle.nl / \ take into account Hofstadter's Law"
Bjorn Engsig
> ... [deletions]
>Casing rules in English are generally formal, not substantive, and
>therefore I consider case to be essentially not significant in normal
>English usage.
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.
mcdo...@uxe.cso.uiuc.edu
>A "I was just wondering" question:
> Why is C case-sensitive?
Who cares? Who cares? Who cares? One would be able to write exactly
the same programs in C whether it began life as case sensitive or not!
(With the possible exception that they might break if you had
two global varibles differing only in case! You see, C really IS
case insensitive for certain things.)
mcdo...@uxe.cso.uiuc.edu
>What I would like is the ability to change text styles, sizes, colors, and
>fonts within my code. I could, for example, have all my comments in a smaller
>point size than my code. Or I could make critical sections of code red.
There are examples of what you want - one is called WEB, invented by
Donald Knuth (it is Pascal). It is the most God-awful mess ever invented.
I do believe that what you want (or need) is a WYSIWYG system. It should
sell great for the Mac. You might make a bundle.
Doug McDonald
Jim Giles
> [...] As long a reasonable
> convention is used for why they differ in case there is little problem.
>
> Personally, I think people who do mixed case like MyVar should be shot!
Unfortunately, irrational conventions often occur. And, since shooting
the programmer is illegal (and doesn't solve the immediate problem anyway),
it would have been better if the feature had never been allowed.
(By the way, if I _NEVER_ had to deal with anyone's code but my own, I too
would probably support case sensitivity. But, I do so I don't.)
>> of code by EMPHASIZING parts that I consider important.
>
> A frightening prospect! [...]
> [...] What you think you
> know what is important to the next guy reading the code? [...]
As often as not, I'm the next person reading the code. I at least know
what I think is important. I any case, the fix for others is obvious
and easy, translate everything to lowercase (as you pointed out). If
the fix for mixed case variables in C were as easy, I would have no
objection to them.
Stephen Uitti
>Fortunately, for both these cases, C has yet to become a really common
>use Fortran-like languages for production.
One may read this as "common usage is x, therefore x is better".
Supers are becoming UNIX based for the same reason that lots of
new machines are UNIX based - because people can do it. No one
wants to implement a new OS (other than maybe Big Blue).
People are writting in Fortran, COBOL, or whatever, because that
is what they know. (Same reason - they can). This has little to
do with what makes a maintainable system.
I've maintained Fortran code. It sucks. Modularity is poor.
Global variables are everywhere. The common statements sometimes
don't match. Some programmer wanted to save an assignment by
switching two names. Pass-By-Name-Only causes all sorts of
strange side effects. Even the straight forward loops have
labels and goto's.
I've maintained BASIC code. No parameter passing. Everything is
global. One and two character variable names. Sigh.
I'm not going to say "C is best", even if this is comp.lang.c.
Still, i have seen vectorizing C compilers on Supers. I've seen
an application get over 150 MFLOPS with it. I've also seen
scientific types who have programmed in Fortran for the last 30
years use it. I think the only reason that they switched from
assembler is that the assembler they learned first disappeared
with the machine(s) they first used. It took years for them to
switch to the "new fangled" Fortran (around 1962?).
If the only well supported scientific language for a
supercomputer was Postscript, you'd find people using it.
You'd even find people who like it.
Stephen.
Stephen Uitti
>> to use case distinctions for related entities. For example,
>> Consider a graph G(V,E)
>> for each vertex v in V do
>> find an edge e in E such that e is incident on v
>> ...
>
>Math texts also tend to use one character identifiers for all objects
>under consideration...
True story. Two physics profs are standing at a blackboard. There
is an equation on the board, something like
2
f(y)ab sin(x)
The one prof is heard to say, "yes, I see f, x, y, a and b, but what
are s, i, and the n function?".
>One last point. I have a color computer a home. To me, having a
>case sensitive language is as bad as having a _color_ sensitive one.
>Can you imagine?!? Consider a program with 512 different variables,
>all spelled "a". How would _YOU_ like to try to debug such a monster?
And your color printer only prints 16 different colors. What is the
ASCII value of a red 'a' anyway?
Stephen.
Jim Giles
> However, if you don't like C, you're doing the readers of this newsgroup
> a disservice by complaining about it, just as it does nobody any good
> for VMS advocates to argue that UNIX is awful in the UNIX newsgroups.
I agree entirely with this assessment. In fact, I was going to recommend
that this thread of the discussion be moved to comp.lang.misc where it
is at least plausible that program language design features can be
discussed with a eye toward the design of new languages. Examination
of the percieved mistakes in C has a valid application in this context.
> [...] If it weren't too late now,
> suggestions about ways to improve the language would have been useful
> too. (I don't recall seeing yours in the mountain we had to wade
> through before or during the public reviews of the proposed C standard.)
I read the draft standard cover-to-cover. I disqualified myself on making
comment, however, because most of my objections to the language involve
features that most people consider to be the 'heart' of C. A suggesion
that intrinsic operators with side-effects should not be implemented would
hardly have been accepted as serious criticism by a committee standardizing
C, for example.
Jim Giles
> 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.
David Dyer-Bennet
>vice versa.
Certainly not; however, both activities are performed using words and
wordlike character groupings. I maintain that it is silly for the
new upstart activity (programming) to establish rules that are in
conflict with the rules of the old, established activity (reading).
This only makes it harder to learn C programming, and causes lingering
errors for years (or forever).
--
David Dyer-Bennet, d...@terrabit.fidonet.org, or d...@ns.network.com
or d...@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