kelem@aero2.arpa (06/13/86)
There is a 429 year precedent of using the symbol = for equality.
The original rationale for using = for equality was given by Robert Recorde
in 1557.
The explanation was "... to auoide the tediouse repetition of these woordes:
is equalle to: I will sette as I doe often in woorke vse,
a paire of paralleles, or Gemowe lines of one lengthe, thus:
=, {a very long equals sign} bicause noe .2. thynges, can be moare equalle."
Granted, spelling is not the same, but = has served as equals in Mathematics
for centuries. Fortran changed the meaning of = to assignment and equality
was spelled ".EQ.". Algol 60 reverted to = for equality and used ":=" for
assignment. This convention was followed by some of its successors: Algol 68,
Pascal, and Ada. PL/I used = for both assignment and equality so that one
could write confusing statements like " a = b = c; " (compare b with c and
assign to a).
The argument put forth in Kernighan and Ritchie is:
"Since assignment is about twice as frequent as equality testing in typical
C programs, it's appropriate that the operator be half as long."
1. There are over four centuries of mathematics using = for equals.
Using = to mean assignment is begging for confusing code.
2. Assignment is a relatively new concept and a new notation is warrented.
":=" has enough precedent to serve this purpose.
Is it really worth using a notation that is contrary to that of the more
universal mathematics, and thus guaranteed to confuse novices and catch pros
off-guard in order to type "=" instead of ":="? I think adding a few
characters to improve readability and understandability is worth the
time and effort.
Consequently, I wrote a pre-processor for C called ac68 that uses := for
assignment, = for equality, and has all the cumulative operators in the
style of Algol 68: +:=, -:=, *:=, &:=, <<:=, etc. Unfortunately, the C
and dbx messages refer to the operators that get generated. Still, the
code is a lot more readable.kjm@ut-ngp.UUCP (06/19/86)
[] >There is a 429 year precedent of using the symbol = for equality. There is a multi-billion year precedent for the non-existance of computers on this planet. Does that mean we should trash all of them? >[...] is equalle to: I will sette as I doe often in woorke vse, >a paire of paralleles, or Gemowe lines of one lengthe, thus: >=, {a very long equals sign} bicause noe .2. thynges, can be moare equalle." ^^^^^^^^^^^^^^^^^^^^^^^ C has this already. To wit: '=='. -- The above viewpoints are mine. They are unrelated to those of anyone else, including my cat and my employer. Ken Montgomery "Shredder-of-hapless-smurfs" Member of HASA -- Heathen and Atheistic Scum Alliance ...!{ihnp4,allegra,seismo!ut-sally}!ut-ngp!kjm [Usenet, when working] kjm@ngp.{ARPA,UTEXAS.EDU} [Old/New Internet; depends on nameserver operation] kjm@ngp.CC.UTEXAS.EDU [Very New Internet; may require nameserver operation]
guy@sun.UUCP (06/19/86)
> Is it really worth using a notation that is contrary to that of the more > universal mathematics, and thus guaranteed to confuse novices and catch pros > off-guard in order to type "=" instead of ":="? I think adding a few > characters to improve readability and understandability is worth the > time and effort. Is it really worth changing a well-established language syntax, in such a way that would break the hell out of existing programs, in order to conform with what is admittedly the dominant notation? I think leaving C alone to keep from breaking existing programs and programmers is worth the confusion it may cause to some people. > Consequently, I wrote a pre-processor for C called ac68 that uses := for > assignment, = for equality, and has all the cumulative operators in the > style of Algol 68: +:=, -:=, *:=, &:=, <<:=, etc. Unfortunately, the C > and dbx messages refer to the operators that get generated. Still, the > code is a lot more readable. Unless you advertise the language accepted by this preprocessor as a language which is similar to C, but is NOT C, I sincerely doubt that. I find that the fake ALGOL 68 crap that Steve Bourne used to write the Bourne shell and "adb" to make the code a lot *less* readable. Let C be C! -- Guy Harris {ihnp4, decvax, seismo, decwrl, ...}!sun!guy guy@sun.com (or guy@sun.arpa)
peters@cubsvax.UUCP (Peter S. Shenkin) (06/19/86)
In article <brl-smok.1331> kelem@aero2.arpa writes: >There is a 429 year precedent of using the symbol = for equality. > >The original rationale for using = for equality was given by Robert Recorde >in 1557. >The explanation was "... to auoide the tediouse repetition of these woordes: >is equalle to: I will sette as I doe often in woorke vse, >a paire of paralleles, or Gemowe lines of one lengthe, thus: >=, {a very long equals sign} bicause noe .2. thynges, can be moare equalle." .... >1. There are over four centuries of mathematics using = for equals. >Using = to mean assignment is begging for confusing code. >2. Assignment is a relatively new concept and a new notation is warrented. >":=" has enough precedent to serve this purpose. Assignment is also ancient in mathematics. It is usually invoked in formal writing by a phrase such as "Let z equal x/y". In informal writing, such as Recorde's "worke vse," it occurs as "z = x/y". What's recent is the need to distinguish between a statement of equivalence (C's "==") and the active process of giving a symbol a value (C's "="). Presumably this came about when mathematicians had to start talking to machines too stupid to be able to infer the distinction from context, instead of to other mathematicians. In any case, I think it's inaccurate to state that "=" traditionally means only one of those things; certainly the spelled-out version, "equal," is used for both meanings in formal mathematics. This all started with the observation that it's easy to say "if( a = b )" when one means "if( a == b )". Most of us probably do this now and then, but it's not really that big a deal, is it? (That is, it's one of the things we look for when debugging, right?) Peter S. Shenkin Columbia Univ. Biology Dept., NY, NY 10027 {philabs,rna}!cubsvax!peters cubsvax!peters@columbia.ARPA
nather@ut-sally.UUCP (Ed Nather) (06/20/86)
In one important sense, the use of "=" as an assignment operator is
extremely unfortunate (though widespread) because, historically, it
meant "equality" in the mathematical sense. Thus the phrase
i = i + 1
is impossible unless i has the value "infinity". We have come to
understand this, however, to mean "increase the value of i by 1"
so the sense of "equality" has been replaced by the time-dependent
assignment process.
Equality has bad connotations in many ways: it implied, at one time,
a "universal, timeless" sort of equivalence, and many mathematicians
came to think of things being "eternally equal" -- in the sense that
time-dependence did not enter. Yet the essential character of a
computer (when it is up) is change with time. So even the use of
"==" for equality isn't the same: the phrase
if(i == 1)
says "if i CURRENTLY has the value 1, then ..." which has the implication
of change, or at least potential change, built in.
Early Algol used a left-pointing arrow as the assignment operator, but that
was not included in the ASCII character set; that decision may be one of
the costliest technical blunders of our time.
--
Ed Nather
Astronomy Dept, U of Texas @ Austin
{allegra,ihnp4}!{noao,ut-sally}!utastro!nather
nather@astro.AS.UTEXAS.EDUcgw@mruxe.UUCP (C Waldman) (06/20/86)
In article <1331@brl-smoke.ARPA>, kelem@aero2.arpa writes: > There is a 429 year precedent of using the symbol = for equality. ...quote deleted... > 1. There are over four centuries of mathematics using = for equals. > Using = to mean assignment is begging for confusing code. > > 2. Assignment is a relatively new concept and a new notation is warrented. > ":=" has enough precedent to serve this purpose. > > Is it really worth using a notation that is contrary to that of the more > universal mathematics, and thus guaranteed to confuse novices and catch pros > off-guard in order to type "=" instead of ":="? I think adding a few > characters to improve readability and understandability is worth the > time and effort. No, no, no! It seems like you are a little confused about the meaning of the equals sign in mathematics. It's true that math uses = for equals, C uses = for equals too. The problem is that there are three meanings of 'equals': "math uses = for equality" is a true, but totally ambiguous statement. The three meanings, as I see them: A) test for equality, as in 'is x equal to 6?' (interrogative) B) assignment of equality, as in 'let x equal 6!' (imperative) C) assertion of equality, as in 'on a right triangle the square of the hypotenuse is equal to the sum of the squares of the two shorter sides.' (declarative) Meanings B and C (and rarely A) are used in math, with only one symbol (=); and your claim that "assignment is a relatively new concept" is erroneous. In programming, we do not state theorems (yes, there are some programs that can chew up theorems, but they don't classify as programming languages), we are interested in telling the computer to DO something: therefore we are interested in meanings A and B. They are both 'equals', but in different senses. We need two symbols to avoid ambiguity. As a user of both C and Pascal, I can appreciate the logic in using the shorter symbol for the more commonly used meaning (I HATE typing :=, especially since you have to hit SHIFT to get the colon, half the time, if I'm typing fast, I get :+). If anything, maybe I would agree with a different symbol for meaning A, like ?= or =? or something, but it's not worth making a change. If it ain't broke, don't fix it.
chris@umcp-cs.UUCP (Chris Torek) (06/21/86)
In article <115@mruxe.UUCP> cgw@mruxe.UUCP (C Waldman) writes: [Mathematical use of the symbol `=' includes three meanings: test for equality, assignment of equality, and assertion of equality.] >[When programming] we are interested in telling the computer >to DO something: therefore we are interested in [the first two] >meanings.... We need two symbols to avoid ambiguity. Fine so far; I think everyone agrees on this (with the exception mentioned in some of the unquoted text of theorem-proving languages). >... If anything, maybe I would agree with a different symbol for >[the first] meaning..., like ?= or =? or something, but it's not >worth making a change. If it ain't broke, don't fix it. Here is where you will, with some, `run into a brick wall' (as they never did say in Bree). Some will claim that it *is* broken, because people do at times write if (var = expr) ... when they in fact meant if (var == expr) ... As for myself, I believe that anyone can do bad things in any language (includin' English like I's a-doin' right here now right before your very own eyes doncha know :-) ), and that the proper measure of a language is not how difficult it makes writing bad code, but rather how easy it makes writing good code. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 1516) UUCP: seismo!umcp-cs!chris CSNet: chris@umcp-cs ARPA: chris@mimsy.umd.edu
grr@cbmvax.cbm.UUCP (George Robbins) (06/21/86)
In article <5166@ut-sally.UUCP> nather@ut-sally.UUCP (Ed Nather) writes: > >Early Algol used a left-pointing arrow as the assignment operator, but that >was not included in the ASCII character set; that decision may be one of >the costliest technical blunders of our time. > >Ed Nather Astronomy Dept, U of Texas @ Austin The Burroughs B5500 algol compilers accepted back-arrow as an assignment operator and it was beautiful! Earlier versions of ASCII included the back-arrow and up-arrow as graphics, but they were replaced by the underline (very useful) and circumflex (less). I really didn't like this change, but then imagine trying to explain to a naive user that the two up-arrow keys on his tube do different things! Almost as bad as IBM keyboards... -- George Robbins - now working with, uucp: {ihnp4|seismo|caip}!cbmvax!grr but no way officially representing arpa: cbmvax!grr@seismo.css.GOV Commodore, Engineering Department fone: 215-431-9255 (only by moonlite)
bzs@bu-cs.UUCP (Barry Shein) (06/22/86)
I'll risk stating it even more strongly than has been said so far: It is not even clear that assignment and equality are clearly distinguished in any mathematical sense, you just think they are because you are applying a particular model of the machine you are computing on. One can envision an environment where the distinction breaks down even further: A few years ago I worked for a company which had me write a compiler with a very similar syntax to C (actually, a superset) who's semantics created a constraint network for a directed graph pseudo-machine. Basically, '=' was simply an assertion that at this point in the computation this statement was 'true' or should be made such (or, possibly, an error if it was not.) Full blown expressions were allowed on either sides of an 'assignment' thus: j = 5; i + 4 = j; simply meant that by the time the second statement was executed if 'i' was empty it was to be given the value '1'. If it was not empty it either already was '1' or indicated an error. Thus statements could be run 'backwards' to infer missing data or verify existing state of the data base. Essentially the whole program ran at once in parallel (as far as the semantics were concerned, not in fact) so the phrase above "by the time the second statement was executed..." is simply a pedagogical convenience. I think such an example should sufficiently blur rigid views towards assignment and equality. Another point would be that I have never seen a mathematician hesitate to introduce notational systems when convenient. Yet another point would be it is not clear that programming and it's languages *isn't* mathematics, rather than two things to be judged side by side. Perhaps the paradigm has shifted? -Barry Shein, Boston University
daveh@cbmvax.cbm.UUCP (Dave Haynie) (06/24/86)
> Here is where you will, with some, `run into a brick wall' (as they > never did say in Bree). Some will claim that it *is* broken, > because people do at times write > > if (var = expr) ... > > when they in fact meant > > if (var == expr) ... > > As for myself, I believe that anyone can do bad things in any > language (includin' English like I's a-doin' right here now right > before your very own eyes doncha know :-) ), and that the proper > measure of a language is not how difficult it makes writing bad > code, but rather how easy it makes writing good code. > -- I could just as easily write in PASCAL, M2, or ADA IF var := expr THEN ... when I mean IF var = expr THEN ... Of course the compiler will flag me about this, but what I get for that compiler error message is the loss of my assignment OPERATOR, replaced by a special case of assignment, the assignment STATEMENT. Certainly there may be less chance of error with the PASCAL style arrangement, at least for beginners. But I KNOW C, and even at 4:00 AM I don't think I've made the assignment/comparison transposition error for a few years. But I use assignment as an operator ALL THE TIME. The PASCAL syntax is like much about PASCAL versus C; PASCAL forces you into a limited means of expression in return for catching your errors for you. This is like giving a dull scalpel to a surgeon; he can't cut himself with it. > In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 1516) > UUCP: seismo!umcp-cs!chris > CSNet: chris@umcp-cs ARPA: chris@mimsy.umd.edu -- /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ Dave Haynie {caip,ihnp4,allegra,seismo}!cbmvax!daveh A quote usually goes here, but its currently being rennovated. These opinions are my own, though for a small fee they be yours too. \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
JUNG_E%SITVXA.BITNET@WISCVM.WISC.EDU (06/25/86)
Although this may be read by all, it is targetted for Ken "Smurf Shredder" Montgomery at U Texas, self-acknowledged scum. Why can't C be like everybody else? Practically every language uses the equals sign, "=", to test for equality, not as an assignment operator. Everybody who's anybody knows that there is a problem in the use of "=" for more than one purpose, a la BASIC and FORTRAN. Pascal resolves this problem by continuing to use "=" to testing and creating ":=" for assignments. Kernighan and Ritchie, in their infinite wisdom, decide instead to use "=" for assignments and to create a new operator, "==" to test for equality. Gee, that must have required brains, the brains of a 3 year old. If they had my brains, they would have used Pascal's method. Better yet, they should have let someone else write up C. Edward Jung, Stevens Institute of Technology JUNG_E@SITVXB.BITNET PS: Ken, I don't like your cat.
chris@umcp-cs.UUCP (Chris Torek) (06/30/86)
In article <1645@brl-smoke.ARPA> JUNG_E%SITVXA.BITNET@WISCVM.WISC.EDU writes: >Why can't C be like everybody else? It is too late for C to be like anything else; it is like C. Besides, if it were exactly like (say) Pascal, it would *be* Pascal. There is room for many languages. >Practically every language uses the equals sign, "=", to test for >equality, not as an assignment operator. Perhaps you know more languages than I. Let me list those whose syntax I remember, and count `= for assigment' vs. `= for equality' (or both). Assignment Equality ---------- -------- Algol APL awk BASIC (really both) FORTRAN Icon Lisp (neither really) Mesa Pascal Snobol Well, 5 to 3 in favour of `= for equality', though APL and Mesa are perhaps special cases: back-arrow is not available for assignment on my H19. >Kernighan and Ritchie, in their infinite wisdom, decide >instead to use "=" for assignments and to create a new operator, "==" to >test for equality. Gee, that must have required brains, the brains of >a 3 year old. Both Brian Kernighan and Dennis Ritchie have quite a bit of experience designing and using languages. Rather than spewing insults, it might be more productive to do some studies as to whether the symbols used for assignment and testing affect programming speed and error rates, for both novice and experienced programmers. Perhaps they did what they did because of some particular insight that others have missed, or perhaps it was a mistake. As far as I can tell, you have not even attempted to determine this experimentally. >If they had my brains, they would have used Pascal's method. Better yet, >they should have let someone else write up C. >Edward Jung, Stevens Institute of Technology >JUNG_E@SITVXB.BITNET If C were different, it would be different. That tells us nothing. C as it is now is quite obviously rather popular. How many languages have you designed, and who is using them? -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 1516) UUCP: seismo!umcp-cs!chris CSNet: chris@umcp-cs ARPA: chris@mimsy.umd.edu
mangoe@umcp-cs.UUCP (Charley Wingate) (06/30/86)
Actually, the only real problem in confusing equality with assignment is when people try to put assignments in expressions to get side effects, at least in procedural languages. PL/I solves the problem neatly (when's the last time you heard THAT about PL/I?) by having a special assignment-in-an-expression operator. The only language that actually followed the mathematics convention was BASIC as it existed before micros, when the magic word LET was generally required. What we really need is a one-character assignment operator; only APL has the optimal solution as it stands. The C convention is unfortunate for two reasons; first, it's unlike everyone else's, and second, confusing the operators is not likely to result in a syntax error. (Chris, I can't imagine why you mentioned Snobol. In my view, saying that snobol does something in such and such a way is tantemount to saying that we should find another way to do it.) C. Wingate
chris@umcp-cs.UUCP (Chris Torek) (06/30/86)
In article <2210@umcp-cs.UUCP> mangoe@umcp-cs.UUCP (Charley Wingate) writes: >(Chris, I can't imagine why you mentioned Snobol. In my view, saying that >snobol does something in such and such a way is tantemount to saying that we >should find another way to do it.) I was specifically avoiding making any judgement calls. I happen to agree that Snobol syntax is exceedingly ugly, and I find it interesting to note that Griswold used `:=' in Icon, which is sort of a `Snobol done right'. Personally, it makes no real difference to me what a language uses for assignment. It takes a few minutes for me to switch between `Algol mode' and `C mode', but afterward everything just flows right on out. Had C used := for assignment, I think I would be just as happy with the language. Ah well. As they say, `too late now.' -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 1516) UUCP: seismo!umcp-cs!chris CSNet: chris@umcp-cs ARPA: chris@mimsy.umd.edu
faustus@ucbcad.BERKELEY.EDU (Wayne A. Christopher) (06/30/86)
In article <1645@brl-smoke.ARPA>, JUNG_E%SITVXA.BITNET@WISCVM.WISC.EDU writes: > Why can't C be like everybody else? Practically every language uses > the equals sign, "=", to test for equality, not as an assignment operator. This is a useless argument, since it won't change anything... However, I can't agree that K&R were mistaken -- just because all other languages use = differently, that doesn't mean that they had to. I think their argument in favor of = and == is a good onew, certainly better than "Pascal uses := for assignment". If I use C 90% of the time and other languages 10% of the time, I think it makes more sense to ask "Why can't the other languages be like C..." > If they had my brains, they would have used Pascal's method. The fact that Pascal uses := is an argument against it, since Pascal is simply *ugly*... Wayne
flaps@utcs.UUCP (07/01/86)
In article <1645@brl-smoke.ARPA> JUNG_E%SITVXA.BITNET@WISCVM.WISC.EDU writes: >Why can't C be like everybody else? Practically every language uses >the equals sign, "=", to test for equality, not as an assignment operator. >... > Kernighan and Ritchie, in their infinite wisdom, decide >instead to use "=" for assignments and to create a new operator, "==" to >test for equality. Not only that, they changed "begin" and "end" to { and }, changed "writeln" to puts, and all sorts of awful things! They made it into a WHOLE NEW LANGUAGE!!!!!
terry@brl-smoke.ARPA (Terry Sejnowski ) (07/01/86)
In article <1645@brl-smoke.ARPA> JUNG_E%SITVXA.BITNET@WISCVM.WISC.EDU writes: >... >Why can't C be like everybody else? Practically every language uses >the equals sign, "=", to test for equality, not as an assignment operator. > ... Kernighan and Ritchie, in their infinite wisdom, decide >instead to use "=" for assignments and to create a new operator, "==" to >test for equality. Gee, that must have required brains, the brains of >a 3 year old. > >If they had my brains, they would have used Pascal's method. Better yet, >they should have let someone else write up C. When I first read the above I was ready to flame away, but I decided to check my facts and come back to it later. Well now I'm ready. :-) The poster of the message above implies that K&R didn't have the faintest idea what they were doing and didn't bother to examine other languages (specifically Pascal) before going on their merry way. Well this sounded sort of fishy to me and I checked out the dates. Ancestory of C Ancestory of Pascal -------------- ------------------- Algol 60 - 1960 (Inter. Comm.) Algol 60 - 1960 (Inter. Comm.) CPL - 1963 (Cambridge and UL) Pascal - draft written - 1968 (Wirth) BCPL - 1967 (Martin Richards) Pascal - first compiler - 1970 B - 1970 (Ken Thompson) Pascal - first publication - 1971 C - 1972 (Dennis Ritchie) Pascal - revised report - 1973 Seems to me that it would be kind of hard to justify using Pascal as the basis for further work when at best it had been in use for a year or two. My impression is that around that time a lot of languages were being written and picking the winners would have taken a crystal ball. As to the symbols used to denote assignment and test for equality, I couldn't find any information on B, but the book on BCPL used := for assignment and = to test for equality. It also used = to set the value of a named constant. It took me a minute to realize what was going on there so I can see re-examining the issue when designing a new language. Quick Jab: If Pascal is so good why did its author (N. Wirth) write two other languages (Modula & Modula II) before deciding he had one which could be used for system implementation? (Lilith (sp?)) Bill Bogstad bogstad@hopkins-eecs-bravo.arpa Disclaimer: The above is true to the best of my knowledge. Corrections cheerfully accepted. Flames to /dev/null.
rbj@icst-cmr (Root Boy Jim) (07/01/86)
> Quick Jab: > If Pascal is so good why did its author (N. Wirth) write > two other languages (Modula & Modula II) before deciding he had one > which could be used for system implementation? (Lilith (sp?)) Really! Pascal: The language that could have been C. Wirth is an idiot. Blaise is rolling over in his grave. (Root Boy) Jim Cottrell <rbj@icst-cmr.arpa> The opinions expressed are my own.
daveh@cbmvax.cbm.UUCP (Dave Haynie) (07/02/86)
> Quick Jab: > If Pascal is so good why did its author (N. Wirth) write > two other languages (Modula & Modula II) before deciding he had one > which could be used for system implementation? (Lilith (sp?)) > > Bill Bogstad > bogstad@hopkins-eecs-bravo.arpa Never any question about this one. Wirth designed Pascal as a teaching language, not a system implementation language, and as a language that could be easily compiled by a 1-pass compiler on small computers. It was designed specifically to be used by novices, thus the very strong type-checking, bounds checking, etc., and the very limited power of the language. Modula 2 seems like and attempt to create a spin-off of the Pascal methodology that can actually be used for system implementation and the like. Probably just as reasonable as all the incompatibly-expanded Pascals around today. -- /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ Dave Haynie {caip,ihnp4,allegra,seismo}!cbmvax!daveh A quote usually goes here, but its currently being rennovated. These opinions are my own, though for a small fee they be yours too. \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
jimc@iscuva.UUCP (Jim Cathey) (07/03/86)
Why did Algol use := in the first place? Why not some other symbol? Was it just because it was easy to type on the keypunch? (I think it was a quick roll off the F to the V key with the shift down or somesuch). This makes no sense to me as I recall that Algol was invented in much the same way as APL was -- as a language for humans to express computer operations. It was only implemented later. Who knows (who cares?). If it was because of the keypunch, I wish that its demise would have followed the Model 60. := is a beach to type on every ASCII 'board I've ever used. Some other easy combo should have been chosen... ;-) -- +----------------+ ! II CCCCCC ! Jim Cathey ! II SSSSCC ! ISC Systems Corp. ! II CC ! Spokane, WA ! IISSSS CC ! UUCP: ihnp4!tektronix!reed!iscuva!jimc ! II CCCCCC ! (509)927-5757 +----------------+ "With excitement like this, who is needing enemas?"
MEYER@RADC-TOPS20.ARPA (07/04/86)
I know this is going to cause a bit more of a stir here, here goes. Everybody keeps guessing at the reasons for the use of = for asignment and == for equality tests. How about a different angle: how many times in a program do you assign something versus how many times you compare things? I seems to me that if it comes down to keystrokes (which by the way is why a lot of UNIX commands are two or three letters long) I'll take = for assignment any day. When I was writing PASCAL programs, Mmy most common error was typing '=' when I meant ':='. Also, if you think about it, the use of == is not so bad 'cuz it is the same character typed twice as opposed to two keys in entirely different places on the keyboard in which one of them has to be shifted and the other not. I prefer not to have to perform keyboard acrobatics to type in a program. Maybe Mssrs. Kernighan and/or Ritchie would like to give some input on their reasons of choice. -------
rmarti@sun.UUCP (07/07/86)
> Everybody keeps guessing at the reasons for the use of = for asignment > and == for equality tests. How about a different angle: how many times > in a program do you assign something versus how many times you compare things? > > [ ... ] > > Maybe Mssrs. Kernighan and/or Ritchie would like to give some input on > their reasons of choice. > ------- They already did. Let me quote K&R, p.17: The double equals sign == is the C notation for "is equal to" (like Fortrans's .EQ.). This symbol is used to distinguish the equality test from the single = used for assignment. Since assignment is about twice as frequent as equality testing in typical C programs, it's appropriate that the operator be half as long. Personally, I still prefer := for assignment and = for equality over = and ==. I also think that the keystroke argument is ridiculous (flames to /dev/null). The problem with = and == is further aggravated by the fact that in C an assignment is an expression and not a statement, so that code like if (i = 0) { /* do something */ } else { /* do something else */ } is legal C and usually /* does something else */ than you expected :-) Despite that, I would never call Messrs K&R idiots, as Niklaus Wirth has been labeled in a recent message (not the one I am responding to): I think both C and Pascal have been reasonable designs of programming languages and important contributions to the computing community. -- Robert Marti, Sun Microsystems, Inc. UUCP: ...{cbosgd,decvax,decwrl,hplabs,ihnp4,pyramid,seismo,ucbvax}!sun!rmarti ARPA: rmarti@sun.com
kjm@ut-ngp.UUCP (07/08/86)
[] JUNG_E%SITVXA.BITNET@WISCVM.WISC.EDU (Edward Jung) posts the following missive: >Although this may be read by all, it is targetted for >Ken "Smurf Shredder" Montgomery at U Texas, self-acknowledged scum. Member of HASA, you mean. (BTW, Oleg, do I qualify as a charter member?) >Why can't C be like everybody else? Practically every language uses >the equals sign, "=", to test for equality, not as an assignment operator. Why should it be like everybody else? Are you really advocating conformity at the expense of innovative improvement? >Everybody who's anybody knows that there is a problem in the use of "=" >for more than one purpose, a la BASIC and FORTRAN. Ah, yes. Once again, Usenetters, we have a personal attack. (Not to mention a confused missive-poster: "=" is only used for assignment in FORTRAN.) >Pascal resolves this >problem by continuing to use "=" to testing and creating ":=" for >assignments. Kernighan and Ritchie, in their infinite wisdom, decide >instead to use "=" for assignments and to create a new operator, "==" to >test for equality. Gee, that must have required brains, the brains of >a 3 year old. Oh, boy! Another personal attack! You must have been in a maximally awful mood when you wrote this missive! >If they had my brains, they would have used Pascal's method. Better yet, >they should have let someone else write up C. Wow! Rack up three for that man! (Give him a cigar? Maybe an exploding one?) One completely reactionary statement. Three personal attacks. Statement Fu. Operator Fu. Confusion Fu. Impressive. Not positively. Smurf-shredder says, "Check it out!" >Edward Jung, Stevens Institute of Technology >JUNG_E@SITVXB.BITNET > >PS: Ken, I don't like your cat. This is about as rational an opinion as the rest you've shown so far. -- The above viewpoints are mine. They are unrelated to those of anyone else, including my cat and my employer. Ken Montgomery "Shredder-of-hapless-smurfs" Member of HASA -- Heathen and Atheistic Scum Alliance ...!{ihnp4,allegra,seismo!ut-sally}!ut-ngp!kjm [Usenet, when working] kjm@ngp.{ARPA,UTEXAS.EDU} [Old/New Internet; depends on nameserver operation] kjm@ngp.CC.UTEXAS.EDU [Very New Internet; may require nameserver operation]
daveh@cbmvax.cbm.UUCP (Dave Haynie) (07/08/86)
> Personally, I still prefer := for assignment and = for equality over = > and ==. I also think that the keystroke argument is ridiculous (flames > to /dev/null). The problem with = and == is further aggravated by the > fact that in C an assignment is an expression and not a statement, so > that code like > > if (i = 0) { > /* do something */ > } > else { > /* do something else */ > } > > is legal C and usually /* does something else */ than you expected :-) As long as you're writing in C, and you REALLY know the language, the above construct would be ridiculous. I think that most of the folks that are unhappy with the way that C handles = and == are frustrated Pascal hackers who can't quite adjust to the power and terseness of C. Maybe if they'd spend a few extra hours LEARNING C instead of trying to write Pascal in C, they'd be much better off. I've had no trouble switching to := and = for Pascal and M2, = and .EQ. for Fortran, = and = for BASIC, = and EQ() for SNOBOL, MAKE and = for LOGO, (LET ), (SET ), (SETQ ) and (EQ ), (EQUAL ) in LISP, or even MOVE and CMP in Assembler. My point is instead of tripping over the language syntax and screaming how it should be changed, one can learn the language and then not have to worry about tripping over it. And then you might even start to realize why a particular method has its advantages. -- /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ Dave Haynie {caip,ihnp4,allegra,seismo}!cbmvax!daveh A quote usually goes here, but its currently being rennovated. These opinions are my own, though for a small fee they be yours too. \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
rbj@icst-cmr (Root Boy Jim) (07/08/86)
> They already did. Let me quote K&R, p.17: > > The double equals sign == is the C notation for "is equal to" (like > Fortrans's .EQ.). This symbol is used to distinguish the equality > test from the single = used for assignment. Since assignment is about > twice as frequent as equality testing in typical C programs, it's > appropriate that the operator be half as long. And since `if' clauses are twice as frequent as `else' clauses, the former token should be half the length of the latter :-) > Personally, I still prefer := for assignment and = for equality over = and ==. Then you would mistype `a = b' instead of `a := b'. > I also think that the keystroke argument is ridiculous (flames to /dev/null). Me too. Since most statements are one to a line, requiring `;' is kind of redundant. Make newline imply `;' unless the statement is incomplete, such as a control statement or unbalanced parens, or dyadic operators at the end of line. Use `;' to jam multiple statements on one line. As always, `\' newline is ignored. > The problem with = and == is further aggravated by the > fact that in C an assignment is an expression and not a statement, so > that code like Since this feature is only in C, LISP, APL, (& others I don't know about) and not in FORTRAN, BASIC, PASCAL, COBOL, PL/I (?), two separate operators are required in the formers, and only suggested in the latters. One FORTARN compiler (DEC?) (U Md.'s RALPH?) would even convert `IF (A = B)' into `IF (A .EQ. B)' for you. > > if (i = 0) { > /* do something */ > } > else { > /* do something else */ > } > > is legal C and usually /* does something else */ than you expected :-) Yes, only one branch (or none), or loop forever (or not at all). I find these easy to fix. > Despite that, I would never call Messrs K&R idiots, as Niklaus Wirth has > been labeled in a recent message (not the one I am responding to): > I think both C and Pascal have been reasonable designs of programming > languages and important contributions to the computing community. Aw, c'mon, is that all the response my statement generated. Let me try again. Dennis Ritchie is like Jerry Garcia: subtle and sweet, while Nickels Worth is like Jimmy Page*: obvious and without any taste. > Robert Marti, Sun Microsystems, Inc. > > UUCP: ...{cbosgd,decvax,decwrl,hplabs,ihnp4,pyramid,seismo,ucbvax}!sun!rmarti > ARPA: rmarti@sun.com (Root Boy) Jim Cottrell <rbj@icst-cmr.arpa> Is it clean in other dimensions? * if you are a `Led Head', then substitute `Mark Farner' for `Jimmy Page'.
tainter@ihlpg.UUCP (Tainter) (07/08/86)
> In article <1645@brl-smoke.ARPA> JUNG_E%SITVXA.BITNET@WISCVM.WISC.EDU writes: > >Why can't C be like everybody else? Practically every language uses > >the equals sign, "=", to test for equality, not as an assignment operator. > >... > > Kernighan and Ritchie, in their infinite wisdom, decide > >instead to use "=" for assignments and to create a new operator, "==" to > >test for equality. > Not only that, they changed "begin" and "end" to { and }, changed "writeln" > to puts, and all sorts of awful things! They made it into a WHOLE NEW > LANGUAGE!!!!! And ignored rationality for a cutesy orthoganal operator construct which they screwed up anyway. << should be less than, >> greater than, == equal, >= greater or equal, <= less or equal, <> (or >< ) greater than or less than The problems C has are mostly in human readability. Of which, the most glaring is the use of = as assignment and == as comparison. NOTE: I don't recall Algol having a writeln so I don't why you say they changed it to puts. :-) Yes, I know he was claiming comparison to Pascal as reason for objection to C. Pascal has a writeln but it is much more like printf than prints. --j.a.tainter
tainter@ihlpg.UUCP (Tainter) (07/08/86)
> In article <1645@brl-smoke.ARPA> JUNG_E%SITVXA.BITNET@WISCVM.WISC.EDU writes: > It is too late for C to be like anything else; it is like C. Besides, > if it were exactly like (say) Pascal, it would *be* Pascal. There is > room for many languages. > >Practically every language uses the equals sign, "=", to test for > >equality, not as an assignment operator. > Perhaps you know more languages than I. Let me list those whose > syntax I remember, and count `= for assigment' vs. `= for equality' > (or both). > Assignment Equality > ---------- -------- > Algol > APL > awk > BASIC (really both) > FORTRAN > Icon > Lisp (neither really) > Mesa > Pascal > Snobol > Well, 5 to 3 in favour of `= for equality', though APL and Mesa are > perhaps special cases: back-arrow is not available for assignment on > my H19. ADD: Assignment Equality ---------- --------- mathematics logic > -- > In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 1516) > UUCP: seismo!umcp-cs!chris > CSNet: chris@umcp-cs ARPA: chris@mimsy.umd.edu --j.a.tainter
JUNG_E%SITVXB.BITNET@WISCVM.ARPA (07/09/86)
I must apologize for my rash mailing several weeks ago on this
topic. As many of you have pointed out to me, I should have done a little
more research before attempting to tear apart K&R.
Apologies to those of you whose intelligence I must have insulted and
to Stevens Institute of Technology. Being an UNDERGRADUATE majoring in
Electrical Engineering rather than Computer Science, I am but a mere hacker of
small microcomputers and have no right to mention the Institute as my
affiliation.
Thanks to those who politely put me in my place. Really.
Edward Jung
JUNG_E@SITVXB.BITNETargv@sri-spam.ARPA (AAAARRRRGGGGv) (07/09/86)
In article <499@cbmvax.cbmvax.cbm.UUCP> daveh@cbmvax.cbm.UUCP (Dave Haynie) writes: >> if (i = 0) { >> /* do something */ >> } >> else { >> /* do something else */ >> } >> >> is legal C and usually /* does something else */ than you expected :-) > >As long as you're writing in C, and you REALLY know the language, the above >construct would be ridiculous. I disagree and I believe you do, too. If you really look for this construct, it is quite common in C, altho good programmers comment that they know what they're doing here... for example, my favorite: main(argc, argv) char **argv; { char *prog_name, *rindex(); if (prog_name = rindex(*argv, '/')) /* find last '/' in argv[0] */ prog_name++; /* set prog_name to string following last '/' */ else prog_name = *argv; /* program was exec-ed from same dir or in PATH */ /* etc... */ } This sort of thing is also quite common when using other string(3) routines or basically anything which returns char * I like that much better than doing the same thing via: prog_name = rindex(*argv, '/'); if (!prog_name) prog_name = *argv; else prog_name++; I don't like this method as well simply because there are more statements than needed and the previous version isn't that cluttered. Since the nature of this discussion is the use (or misuse) of the = operator, I would say that C was designed more robustly simply because you can do the above whereas PASCAL won't let you. C gives you the choice of doing it if you prefer to and to do it the other way if you really want to (or don't know better). >I think that most of the folks that are >unhappy with the way that C handles = and == are frustrated Pascal hackers >who can't quite adjust to the power and terseness of C. Maybe if they'd >spend a few extra hours LEARNING C instead of trying to write Pascal in C, >they'd be much better off. [etc..] I quite agree. When I used to work at my school helping students, I found that the students who complained about C were those who just wanted to take the course to get out of the requirement (elective general ed for most). Other comp sci majors who complained about C (either in favor of PASCAL or not) were merely pedantic and just wanted their peers to respect them. I even found that the comp sci faculty that pushed PASCAL knew little about C. Although all of the faculty (whether they kenw C or not) agreed that PASCAL was the correct language to learn for freshmen (I am undecided about this), most of them agreed that it was too limiting for the upper-division courses which concentrated on more important issues. dan (argv@sri-spam.arpa)
chris@umcp-cs.UUCP (Chris Torek) (07/09/86)
In article <6056@sri-spam.ARPA> argv@sri-spam.UUCP (AAAARRRRGGGGv) writes: >this construct ... [if (lvalue = rvalue) { ...] is quite common in C, >altho good programmers comment that they know what they're doing here... >for example, my favorite: > >main(argc, argv) >char **argv; >{ > char *prog_name, *rindex(); > > if (prog_name = rindex(*argv, '/')) /* find last '/' in argv[0] */ > prog_name++; /* set prog_name to string following last '/' */ > else prog_name = *argv; /* program was exec-ed from same dir or in PATH */ > /* etc... */ I have come to favour if ((prog_name = rindex(*argv, '/')) != NULL) ... One of these years I will get around to installing Arthur Olson's lint code that gripes about assignments in conditional contexts. Adding the `!= 0' is not difficult and demonstrates your `true intention' quite well. >I would say that C was designed more robustly simply because you can >do the above [if (v = e)] whereas PASCAL won't let you. I think the proper word here is `orthogonal'. Actually, I have a feeling there is an even better word (no not *that* word :-) ), but I cannot recall it now. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 1516) UUCP: seismo!umcp-cs!chris CSNet: chris@umcp-cs ARPA: chris@mimsy.umd.edu
SYSBDES%TCSVM.BITNET@WISCVM.ARPA (Dan Smith) (07/09/86)
I've watched this discussion now for quite a while and finally cann't
stand it anymore. I agree with Dave Haynie when he says that most people
who seem to have a problem with '=' are frustrated pascal programmers. We
should start up some new discussions about C syntax or usage/and/or various
implimentations of C by companies. I've done fortrash/assembler/pascal/c
in my checkered past and have found C's syntax to be quite clear (after you
read K&R) Save us all from the 'Structure' freaks out there that cann't
do anything if they don't have a symbol or box to fit the construct. My
main rule of programming which I always try to follow is "NEVER WRITE A
ROUTINE LARGER THAN ONE SCREEN" Maybe its just me, but this works for me
and produces clean code which others can understand and work on.
Enough of the soap box. I'll prob' get a ton of flames for that but
my finger is getting tired of discarding mail about swap macros and '='
vs ':='. Now lets get on to some new topics such as why several large
software houses have modified the syntax of pointer math on Intel 86
series machines to the point that it no longer fits standard C. Most of
the C compilers which generate 'BIG' model executibles seem to have a
real problem with pointers. Lattice put in code which converts to/from
a 'intel' pointer to a 'abstract' pointer to allow math to work OK but
at a performance cost. Computer Innovations (at least at v2.3) use
'intel' style pointers only for the BIG model. And pointer math takes on
a whole new outlook on life. I've found that neither of these designs
works very well. I've looked at the code generated by Lattice and its
QUITE offensive, it calls a subroutine for every instance of pointer
math to convert the internal pointer into a 'absolute' pointer then
converts it back. Gross.. It would have been better to emit the code
inline and save a ton of overhead. I tried my hand at it and came up
with about a 5 instruction convert in each direction which almost beats
the memory overhead of a arguement setup/call/arguement cleanup. It
definitly beats it as far as speed. These comments pertain to a Lattice
version about 8 months old and might be fixed now.
I know my comments don't really fit the 'Info C' digest I guess it
should be in Info C Compiler Implimentations but I had to try and change
the course of current discussion. I couldn't stand it anymore. I guess
I'll have to put my flame proof shorts on now.. Oh vell...
"Std Disclaimer -- This stuff is the result of my own burnt out mind and
NOBODY elses"
Dan Smith (aka MadMan)
BITNET: SYSBDES@TCSVM
ARPA: SYSBDES%TCSVM.BITNET@WISCVM.WISC.EDU
UUCP: ...psuvax1!tcsvm.bitnet!sysbdes
real soon now !tu-pul!ludwig!ds
Ma Bell: (504) 865-5631
Real Paper: Tulane University
Tulane Computer Services
Attn: Dan Smith, Systems Group
6823 St. Charles Ave.
New Orleans, LA 70118-5698daveh@cbmvax.cbm.UUCP (Dave Haynie) (07/09/86)
> > In article <499@cbmvax.cbmvax.cbm.UUCP> daveh@cbmvax.cbm.UUCP (Dave Haynie) writes: >>> if (i = 0) { >>> /* do something */ >>> } >>> else { >>> /* do something else */ >>> } >>> >>> is legal C and usually /* does something else */ than you expected :-) >> >>As long as you're writing in C, and you REALLY know the language, the above >>construct would be ridiculous. > > I disagree and I believe you do, too. If you really look for this > construct, it is quite common in C, altho good programmers comment > that they know what they're doing here... for example, my favorite: > > main(argc, argv) > char **argv; > { > char *prog_name, *rindex(); > > if (prog_name = rindex(*argv, '/')) /* find last '/' in argv[0] */ > prog_name++; /* set prog_name to string following last '/' */ > else prog_name = *argv; /* program was exec-ed from same dir or in PATH */ > /* etc... */ > } > > This sort of thing is also quite common when using other string(3) routines > or basically anything which returns char * > I like that much better than doing the same thing via: > > prog_name = rindex(*argv, '/'); > if (!prog_name) > prog_name = *argv; > else prog_name++; > > I don't like this method as well simply because there are more statements > than needed and the previous version isn't that cluttered. Since the > nature of this discussion is the use (or misuse) of the = operator, I > would say that C was designed more robustly simply because you can do > the above whereas PASCAL won't let you. C gives you the choice of doing > it if you prefer to and to do it the other way if you really want to (or > don't know better). > Whoa, there! I think we're in agreement here, believe it or not. I've commented before on the great advantages of the assignment OPERATOR in C, which is what you've shown. The case initially presented above is the trivial case, which is ridiculous, since the /* do something */ clause will never be executed. The example that you show is good C, I use that style all of the time, and a good compiler will produce code for it that's more efficient than in the second example. There's no confusion in the if () clause of your first example, since it would be silly to expect an equality test there, with prog_name being an uninitialized variable (in fact, the Lattice C compiler I use on the Amiga would generate an "uninitialized auto variable" warning if I used an == operator there instead of the assignment operator. >>I think that most of the folks that are >>unhappy with the way that C handles = and == are frustrated Pascal hackers >>who can't quite adjust to the power and terseness of C. Maybe if they'd >>spend a few extra hours LEARNING C instead of trying to write Pascal in C, >>they'd be much better off. [etc..] > > I quite agree. When I used to work at my school helping students, I found > that the students who complained about C were those who just wanted to take > the course to get out of the requirement (elective general ed for most). > Other comp sci majors who complained about C (either in favor of PASCAL or > not) were merely pedantic and just wanted their peers to respect them. > I even found that the comp sci faculty that pushed PASCAL knew little about > C. Although all of the faculty (whether they kenw C or not) agreed that > PASCAL was the correct language to learn for freshmen (I am undecided about > this), most of them agreed that it was too limiting for the upper-division > courses which concentrated on more important issues. > > dan (argv@sri-spam.arpa) -- /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ Dave Haynie {caip,ihnp4,allegra,seismo}!cbmvax!daveh "I don't feel safe in this world no more, I don't want to die in a nuclear war, I want to sail away to a distant shore And live like an ape man." -The Kinks These opinions are my own, though for a small fee they be yours too. \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
mangoe@umcp-cs.UUCP (Charley Wingate) (07/10/86)
Dave Haynie writes: >> Personally, I still prefer := for assignment and = for equality over = >> and ==. I also think that the keystroke argument is ridiculous. The >> problem with = and == is further aggravated by the fact that in C an >> assignment is an expression and not a statement, so that code like >> if (i = 0) { >> /* do something */ >> } >> else { >> /* do something else */ >> } >> is legal C and usually /* does something else */ than you expected :-) >As long as you're writing in C, and you REALLY know the language, the above >construct would be ridiculous. I think that most of the folks that are >unhappy with the way that C handles = and == are frustrated Pascal hackers >who can't quite adjust to the power and terseness of C. Maybe if they'd >spend a few extra hours LEARNING C instead of trying to write Pascal in C, >they'd be much better off.[...] My point is instead of >tripping over the language syntax and screaming how it should be changed, >one can learn the language and then not have to worry about tripping over >it. And then you might even start to realize why a particular method has >its advantages. Unfortunately, it's that kind of attitude that leads to the perpetuation of bad language constructs. C's handling of assignment and equality is a problem: it is error-prone. What's worse is that one often sees code like "if (a=b)" done on purpose-- yet another example on how the "power and terseness" of C leads to obfuscation. C. Wingate
chris@umcp-cs.UUCP (Chris Torek) (07/10/86)
>>In article <1645@brl-smoke.ARPA> JUNG_E%SITVXA.BITNET@WISCVM.WISC.EDU writes: Careful with the quotes; the `>>' text is mine, not JUNG_E%SITVXA.BITNET's. (The >>> text is his.) >>>Practically every language uses the equals sign, "=", to test for >>>equality, not as an assignment operator. (Here I listed some languages, and tallied:) >>Well, 5 to 3 in favour of `= for equality', though APL and Mesa are >>perhaps special cases: back-arrow is not available for assignment on >>my H19. In article <2158@ihlpg.UUCP> tainter@ihlpg.UUCP (Tainter) replies: >ADD: > Assignment Equality > ---------- --------- > mathematics > logic >--j.a.tainter Imprimus, the context is really computer languages. Secondus, both mathematics and logic are very broad fields, and saying `mathematics uses ``='' for equality' is like saying `physics uses ``c'' for the speed of light': true in many instances but by no means universal. Tertius, this whole discussion is getting boring. For those of you who prefer := for assignment and `=' for equality, just compile all your C code to .o files with the following `pascalcc' shell script. It can be extended, if necessary, to do most everything that /bin/cc does. : pascalcc - compile C code with Pascal-esque assignment / equality comp=/lib/ccom c2=/bin/cat tf=/tmp/pascalcc.$$ trap "rm -f $tf" 0 1 2 3 15 for i do case "$i" in -O) c2=/lib/c2;; -c) ;; *.c) if cc -E "$i" | sed -e 's/\([^:]\)=/\1==/' -e 's/:=/=/' | $comp | $c2 > $tf; then if as -o `echo "$i" | sed -e 's/\.c$//'`.o $tf; then : else exit $? fi else exit $? fi;; *) echo "$0: cannot handle file name \`$i'" 1>&2 exit 1;; esac done -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 1516) UUCP: seismo!umcp-cs!chris CSNet: chris@umcp-cs ARPA: chris@mimsy.umd.edu
ins_apmj@jhunix.UUCP (Patrick M Juola) (07/10/86)
In article <2158@ihlpg.UUCP> tainter@ihlpg.UUCP (Tainter) writes: >> Perhaps you know more languages than I. Let me list those whose >> syntax I remember, and count `= for assigment' vs. `= for equality' >> (or both). >> Assignment Equality >> ---------- -------- [ List deleted ] >ADD: > Assignment Equality > ---------- --------- > mathematics > logic >--j.a.tainter try mathematics (both) logic (both) You've never seen the statements at the beginning of proofs, where they assign properties to variables.... If you want to assign to vector z the length of 1, you write "|z|=1." Or at least I do. How do you do it? -- seismo!umcp-cs \ Pat Juola ihnp4!whuxcc > !jhunix!ins_apmj Hopkins Maths allegra!hopkins / "I'm kind of tired. I was up all night trying to round off infinity."
emjej@uokvax.UUCP.UUCP (07/10/86)
/* Written 8:15 pm Jul 3, 1986 by MEYER@RADC-TOPS20.ARPA in net.lang.c */
I know this is going to cause a bit more of a stir here, here goes.
Everybody keeps guessing at the reasons for the use of = for asignment
and == for equality tests. How about a different angle: how many times
in a program do you assign something versus how many times you compare things?
/* End of text from net.lang.c */
If that's a reasonable principle of programming language design, then
let's see if we can't get Huffman-coding for C keywords in the next ANSI
draft standard.
= for assignment is one of many flaws in C syntax. Combined with the
absence of a Boolean type, it is a considerable source of errors in C
code. Lint should warn the user of every occurrence of "if (a = b)".
(I predict that at least one C-worshipper will say "*real* C programmers,
as opposed to quiche-eaters, don't make that mistake." I think they're
wrong, based on the instances of it I've seen. Second-order comment
will be "you haven't done a study, so you're not worth bothering with":
I admit that I haven't, but (1) I lack the resources, and (2) it's too
bad the designers of programming languages (and Unix utilities) don't
have to do human factors studies before introducing their products.)
James Jonesaka@cbrma.UUCP (07/10/86)
In article <499@cbmvax.cbmvax.cbm.UUCP> daveh@cbmvax.cbm.UUCP (Dave Haynie) writes: > >... My point is instead of >tripping over the language syntax and screaming how it should be changed, >one can learn the language and then not have to worry about tripping over >it. And then you might even start to realize why a particular method has >its advantages. >-- Amen. -- +----------------------------------------------------------------------------+ | | Andy Kashyap | | | AT&T Bell Labs | | | Columbus OH | | Say Goodnight Gracey...Gracey?...Gracey?!!...HEY!!! | ..!cbosgd!cbrma!aka| +----------------------------------------------------------------------------+
aka@cbrma.UUCP (07/10/86)
In article <6056@sri-spam.ARPA> argv@sri-spam.UUCP (AAAARRRRGGGGv) writes: >In article <499@cbmvax.cbmvax.cbm.UUCP> daveh@cbmvax.cbm.UUCP (Dave Haynie) writes: >>> if (i = 0) { >>> /* do something */ >>> } >>> else { >>> /* do something else */ >>> } >>> >>> is legal C and usually /* does something else */ than you expected :-) >> >>As long as you're writing in C, and you REALLY know the language, the above >>construct would be ridiculous. > >I disagree and I believe you do, too. If you really look for this >construct, it is quite common in C, altho good programmers comment >that they know what they're doing here... for example, my favorite: > >main(argc, argv) >char **argv; >{ > char *prog_name, *rindex(); > > if (prog_name = rindex(*argv, '/')) /* find last '/' in argv[0] */ > prog_name++; /* set prog_name to string following last '/' */ > else prog_name = *argv; /* program was exec-ed from same dir or in PATH */ > /* etc... */ >} > >dan (argv@sri-spam.arpa) Look again, Dan, at the original posting. The 'true' branch of the 'if' statement is *NEVER* executed. -- +----------------------------------------------------------------------------+ | | Andy Kashyap | | | AT&T Bell Labs | | | Columbus OH | | Say Goodnight Gracey...Gracey?...Gracey?!!...HEY!!! | ..!cbosgd!cbrma!aka| +----------------------------------------------------------------------------+
guy@sun.UUCP (07/10/86)
> > if (prog_name = rindex(*argv, '/')) > > prog_name++; > > else prog_name = *argv; ... > > > > prog_name = rindex(*argv, '/'); > > if (!prog_name) > > prog_name = *argv; > > else prog_name++; > The example that you show is good C, I use that style all of the time, > and a good compiler will produce code for it that's more efficient than > in the second example. Assuming your machine stores an indication of whether a "move" instruction moved a zero-or-non-zero value somewhere (which may or may not be the case; the MIPS chip, for example, has no condition code register), and assuming that your C implemention represents null pointers as all-zero bit patterns, a good compiler will realize that in the second example an indication of whether "prog_name" was assigned a zero value will be found there and will use it, in exactly the same fashion as it did in the first example, and will generate equally efficient code for both examples. If the aforementioned assumptions are not true, the conclusion that a good compiler will generate equally efficient code for both examples will almost certainly still be true. -- Guy Harris {ihnp4, decvax, seismo, decwrl, ...}!sun!guy guy@sun.com (or guy@sun.arpa)
mikel@codas.UUCP (07/11/86)
In article <1645@brl-smoke.ARPA> JUNG_E%SITVXA.BITNET@WISCVM.WISC.EDU writes: >Kernighan and Ritchie, in their infinite wisdom, decide >instead to use "=" for assignments and to create a new operator, "==" to >test for equality. Gee, that must have required brains, the brains of >a 3 year old. Where did this clod come from? -- ___ / \ Mikel Manitius @ AT&T-IS Altamonte Springs, FL | RPI | ...{seismo!akgua|ihnp4|cbosgd|mcnc}!codas!mikel | . | \\-------//
gwyn@BRL.ARPA (07/11/86)
Re: "C has problems in human readability": Funny, I don't have problems with all these things like = vs. ==. Last I checked, I was human. Perhaps you meant that C is not a language for neophyte programmers? I've ben saying that for years.
gwyn@BRL.ARPA (07/11/86)
It's not the "power and terseness" of C that leads to obfuscation, but the unthinking exploitation of those features. Otherwise, one would be able to argue by analogy against the automobile, since I suspect far fewer people died in traffic-related accidents when we only used horses. What people need to do is learn to harness the power and use it wisely.
Eric_S._Fanwick.STHQ@Xerox.COM (07/11/86)
The best way to some up the difference between C and Pascal, (I
personnally see strengths and weeknesses in both) is that
C assumes the programmer knows what he is doing and lets him do it.
Pascal assumes the programmer does not know what he is doing and
prevents him.
Given this basic difference makes Pascal a better teaching language
Eric Fanwick
PS: Strong typed languages are for week minds.daveh@cbmvax.UUCP (07/11/86)
> > Unfortunately, it's that kind of attitude that leads to the perpetuation of > bad language constructs. > > C's handling of assignment and equality is a problem: it is error-prone. > What's worse is that one often sees code like "if (a=b)" done on purpose-- > yet another example on how the "power and terseness" of C leads to > obfuscation. > > C. Wingate Hey, you can use assignment in C as if it were a statement only when you write YOUR C code, but in the example that you give its used in its full power as an operator, which can generate much more efficient code than the equivalent: a=b if (b) Personally, I would have coded it if ((a=b) == 0) OR if ((a=b) == NULL) to make my point clear (a good compiler will produce the same code in all three cases, though a bad one may code more efficiently on the first example). But my point is that there's nothing inherently bad about the constructs available in C, there's no confusion if you know the language and don't specifically try to write confusing code (which you can do in languages like APL and LISP much more effectively than in C), and there's additional power in the language for those who know how to use it. You like the verobsity of Pascal, so use Pascal. I like the power of C, which is why I write in it, and I'm not confusing MYSELF with C. Giving Pascal's rules to a good C programmer is like giving a dull scapel to a skilled surgeon; he can't cut himself with it. -- /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ Dave Haynie {caip,ihnp4,allegra,seismo}!cbmvax!daveh "I don't feel safe in this world no more, I don't want to die in a nuclear war, I want to sail away to a distant shore And live like an ape man." -The Kinks These opinions are my own, though for a small fee they be yours too. \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
gwyn@brl-smoke.UUCP (07/12/86)
In article <3147@jhunix.UUCP> ins_apmj@jhunix.ARPA (Patrick M Juola) writes: > You've never seen the statements at the beginning of proofs, where >they assign properties to variables.... If you want to assign to vector >z the length of 1, you write "|z|=1." Or at least I do. How do you do it? Much as I hate to continue this totally bogus discussion, I really have to point out that |z|=1 is not any sort of an assignment. Usually it is seen in a context such as "assume |z|=1; then..." which is a Boolean use of = as a relational operator. But this has nothing to do with C and should move to net.math, if you really want to discuss meaning of symbols in mathematics.
andrew@alice.UUCP (07/12/86)
I don't understand. If you personally have a problem handling the token '=',
don't lay it on everyone else. Getting lint to complain about it is fine by me;
I don't use lint. However, the poor sods who do might (should) object.
There is nothing wrong with this sort of code:
char *s, *getword();
while(s = getword()){
...
}
The more noise lint puts out, the less use it is.
It seems to me you can solve YOUR problems by a preprocessor sed script.
Modifying the C language to avoid this sed step to solve learning
disabilities for a small set of users seems incorrect.guy@sun.UUCP (07/12/86)
> Hey, you can use assignment in C as if it were a statement only when you > write YOUR C code, but in the example that you give its used in its full > power as an operator, which can generate much more efficient code than > the equivalent: > > a=b > if (b) If your compiler can't generate equally efficient code for a = b; if (a != 0) and if ((a = b) != 0) on any machine other than an incredibly weird one, then your compiler needs to be improved. -- Guy Harris {ihnp4, decvax, seismo, decwrl, ...}!sun!guy guy@sun.com (or guy@sun.arpa)
brooks@lll-crg.UUCP (07/13/86)
>= for assignment is one of many flaws in C syntax. Combined with the >absence of a Boolean type, it is a considerable source of errors in C >code. Lint should warn the user of every occurrence of "if (a = b)". Not a bad idea. I don't write this as a matter of policy and I would not mind lint giving a warning. You could even have a flag control it. > >(I predict that at least one C-worshipper will say "*real* C programmers, >as opposed to quiche-eaters, don't make that mistake." I think they're It is true that real programmers don't make mistakes and don't eat quiche either. It has nothing to do with C. Real programmers don't spend their time complaining about using = for assignment either.
gaynor@topaz.UUCP (07/13/86)
In article <5057@sun.uucp>, guy@sun.uucp (Guy Harris) writes: > If your compiler can't generate equally efficient code for > > a = b; > if (a != 0) > > and > > if ((a = b) != 0) > > on any machine other than an incredibly weird one, then your compiler needs > to be improved. Ideally, degrees of optimization should be available, offering trade-offs between code-speed vs code-space vs compilation-time vs code-size, and optional code generation, to name the biggies. For example, when debugging syntax errors, why waste time generating code when all you want to do is check the syntax? When verifying a program's correctness, your not going to need really good code, just something done quick-n-dirty (to save on system resources). For production, the trade-off of code-size vs code-speed rears its ugly head (code-size is very important when, say, you try to port gnu-emacs to a small computer). I reiterate, this is the ideal situation. _ /| \`o_O' ( ) Aachk! Phft! U Disclaimer: The opinions and/or information and/or code expressed here were generated by this characature, stolen from Dave Rasmussen, to which I have taken the liberty of adding ears. So don't look to me for a disclaimer! Silver {...!topaz!gaynor}
guy@sun.UUCP (07/13/86)
> > If your compiler can't generate equally efficient code for > > > > a = b; > > if (a != 0) > > > > and > > > > if ((a = b) != 0) > > > > on any machine other than an incredibly weird one, then your compiler > > needs to be improved. > > Ideally, degrees of optimization should be available, Yeah, they should, but so what? Why is this relevant to the previous comment? It doesn't say "if your compiler doesn't always generate", it says "if your compiler *can't* generate". The claim that constructs like if ((a = b) != 0) are necessary because they generate more efficient code than a = b; if (a != 0) is bogus; compilers *can* be made to generate equally efficient code for both. The fact that you can write things in the first style should *not* be used as an excuse for compiler writers not to do optimization "because the human will do it for you". -- Guy Harris {ihnp4, decvax, seismo, decwrl, ...}!sun!guy guy@sun.com (or guy@sun.arpa)
mangoe@mimsy.umd.edu (07/14/86)
I don't buy your analogy. We aren't talking about the presence or absence of computer languages, after all, we're talking about what they should be like. We like to think that we know what cars ought to be like, and we legislate accordingly. Commercial airliners and railroads are even stronger examples of the same thing. The problem I'm having with the equality discussion (besides my feeling that ASCII's lack of a one-character assignment operator) is that there's this implicit (and occasionally explicitly stated notion) that terseness and power are apriori virtues. I'm not convinced that they are. Verbosity cabn quite obviously be taken to excess; restrictions in the name of protecting the programmer can also be taken to excess. COBOL illustrates the former; Pascal the latter. The problem with C is that the extra power it offers above other high level languages are all really shortcuts inherited from assembly languages. The "=" - "==" similarity plays upon this. C extends an opebn invitation to obscure hand optimizations and deliberately tricky code, to the point where it gives the impression of being written for the express purpose of allowing this. The array-pointer ambiguity is another example; people may rail all they want, but a lot of UNIX source plays upon this ambiguity. In my opinion, the question is whether or not these idiosyncrasies inherited from minicomputer assembly languages are really desirable in this day and age. Six months of reading UNIX source have convinced me that they aren't. Charley Wingate
rmarti@sun.UUCP (07/14/86)
In article <5783@alice.uUCp> Andrew Hume @ Bell Labs, Murray Hill writes: > The more noise lint puts out, the less use it is. Good point. That's precisely why I don't like lint: I hardly ever get a program to pass through lint without getting least a dozen lines of garbage. (Interestingly enough, I do eventually get Pascal and Modula-2 programs to compile without error messages from the compiler ... ) -- Robert Marti, Sun Microsystems, Inc. UUCP: ...{cbosgd,decvax,decwrl,hplabs,ihnp4,pyramid,seismo,ucbvax}!sun!rmarti ARPA: rmarti@sun.com
cgw@mruxe.UUCP (07/14/86)
Why not form a new newsgroup, net.lang.equals, for all those tireless souls who want to drag this issue out ad infinitum..... :-)
rbj%icst-cmr@smoke.UUCP (07/14/86)
If that's a reasonable principle of programming language design, then let's see if we can't get Huffman-coding for C keywords in the next ANSI draft standard. Great! Replace all the keywords by digraphs! = for assignment is one of many flaws in C syntax. Combined with the absence of a Boolean type, it is a considerable source of errors in C code. Lint should warn the user of every occurrence of "if (a = b)". 0 for three. (I predict at least one C-worshipper will say "*real* C programmers, as opposed to quiche-eaters, don't make that mistake." I think they're wrong, based on the instances of it I've seen. Whatever they eat, the mistake is rare (after getting bit a few times), and easy to find when made. Second-order comment will be "you haven't done a study, so you're not worth bothering with": Hey, I can relate to this. If the founding fathers had done a study, we'd never have had the Bill of Rights. Why poll the common man when you have a genius to lead the way. I admit that I haven't, but (1) I lack the resources, and (2) it's too bad the designers of programming languages (and Unix utilities) don't have to do human factors studies before introducing their products.) Human factors are for humans. You are talking to machines. Beep, click, whirr! James Jones No, I *don't* want any Kool-Aid! (Root Boy) Jim Cottrell <rbj@icst-cmr.arpa> I'm pretending I'm pulling in a TROUT! Am I doing it correctly??
rbj%icst-cmr@smoke.UUCP (07/14/86)
The problem I'm having with the equality discussion (besides my feeling that ASCII's lack of a one-character assignment operator) It's called `='. Assignment is imperative, conditionals interrogative. By the time the assignment is done, the conditional is true. In english we say `That's OK!' or `That's OK?' and we don't get confused. [: Making the same symbols mean different things depending on the context 1) is nothing new. :] 2) Is nothing new? D.C. al coda, etc, etc. Perhaps `<-' should have been the assignment operator. After all, they chose `->' for points to when `@' would have done just nicely. C'mon now, nobody *really* used `@' & `#' for erase & kill did they :-) The problem with C is that the extra power it offers above other high level languages are all really shortcuts inherited from assembly languages. The "=" - "==" similarity plays upon this. Allowing assignment in conditionals is no syntactic sugar. It avoids duplication of code by localizing it in one place. C extends an open invitation to obscure hand optimizations and deliberately tricky code, Which mature individuals will learn to avoid. Witness both Chris Torek's and Doug Gwyn's preference for `if ((a = b) != NULL)' over `if (a = b)'. I myself prefer the latter, but what do I know? to the point where it gives the impression of being written for the express purpose of allowing this. You figured it all out! DMR wrote C so everybody could post articles about how smart he is! Who cares about computers anyway? Seriously, what looks like tricks to some is often the limits of their own experience. Why should assignment be any different than `+'? The array-pointer ambiguity is another example; people may rail all they want, but a lot of UNIX source plays upon this ambiguity. It's not ambiguous. It's quite well defined. In my opinion, the question is whether or not these idiosyncrasies inherited from minicomputer assembly languages are really desirable in this day and age. Good point. We really ought to change the names of SIGIOT and SIGEMT. Six months of reading UNIX source have convinced me that they aren't. Which UNIX? Charley Wingate (Root Boy) Jim Cottrell <rbj@icst-cmr.arpa> PEGGY FLEMMING is stealing BASKET BALLS to feed the babies in VERMONT. P.S. Probably from Lefty.
rbj%icst-cmr@smoke.UUCP (07/14/86)
The best way to some up the difference between C and Pascal, (I personnally see strengths and weeknesses in both) is that C assumes the programmer knows what he is doing and lets him do it. Pascal assumes the programmer does not know what he is doing and prevents him. Kind of like Georgia telling you what you can put in your mouth. Given this basic difference makes Pascal a better teaching language Except that Pascal has such other bad features that make it unusable and promote bad habits. People, I don't see why you can't deal with subsets of a language. If you took a first semester FORTRAN class (a rarity these days) and taught it in C (no pointers, no double operators except == (you can even #define _EQ_ ==), no ?:, etc) you would be pretty much teaching in FORTRAN. Hell, you can even lie a little bit: "Arguments are passed by value, except for arrays. Tacking `&' onto the front of a variable `makes an array out of it' (lie, lie). To reference it you need to call it `variable[0]'". After all, when they taught us FORTRAN, I didn't hear anyone complaining about the dangers of the EQUIVALENCE statement. When your pups get a little bigger, you can tell them what's *really* going on. Kind of like reality. But to subject them to the slangs and errors of outrageous fortran, (I meant pascal, but Willie wrote it the other way :-) because a few pop psychologists are afraid of seeing stars, is insane. I saw throw `em in the water and let `em sink or swim. Eric Fanwick PS: Strong typed languages are for week minds. Really! Eight days a weak. (Root Boy) Jim Cottrell <rbj@icst-cmr.arpa> Being a BALD HERO is almost as FESTIVE as a TATTOOED KNOCKWURST.
faustus@ucbcad.UUCP (07/15/86)
I think that most of the people who are keeping this stupid debate going don't know C well and don't like it. In order to keep the flaming down in net.lang.c, PLEASE don't post anything unless you (1) Have used C for > 5 years, and (2) Would not change a single thing about it if you were DMR 15 years ago. This should help the problem a bit... :-) Wayne
gwyn@BRL.ARPA (07/15/86)
> "I hardly ever get a program to pass through lint without getting least a > dozen lines of garbage." Perhaps "lint" is trying to tell you something. I hardly ever get output from "lint"; when I do, it's almost always because I made a coding error, so I'm glad to be told about it.
mangoe@mimsy.umd.edu (07/15/86)
The reasons all really boil down to optimization. The only reason I can see to prefer (a=b) over ((a=b)!=NULL) (why did C have to perpetuate the PL/I mistake on the not-equals operator, anyway?) is efficiency, and this isn't exactly a difficult optimization to do mechanically. I can see that it is useful for some applications to be able to write in what is essentially a high level language containing an assembler, but I don't for a minute believ that it is a virtue. I also don't believe that the C method is the only way to have assignments in expressions and still keep "=" for both purposes. One of PL/I's few virtues is that it recognizes that equality and assignments are both reasonably common, but that assignments in expressions are relatively rare. So it has a special "assignment-with-value" operator. If it is insisted that there is a separate boolean type, then most of the errors in this sort of system can be flagged and corrected. I've been looking at 4.3 code, particularly for the Sun. There are plenty of places where pointers are used indifferently as pointers to structures and as pointers to arrays. There is code which relies on ints and pointers being the same size. There is code which relies on successive declarations being stored contiguously and in order. Code which relies on NULL equalling zero is omnipresent. All this leads me inescapably to the conclusion that C was designed to allow programmers to violate the rules which everyone else is busily putting into their languages to protect themselves. I have to use C, but I'm not at all happy with what itclaims as features. CGW
colonel@sunybcs.UUCP (Col. G. L. Sicherman) (07/15/86)
> >As long as you're writing in C, and you REALLY know the language, the above > >construct would be ridiculous. I think that most of the folks that are > >unhappy with the way that C handles = and == are frustrated Pascal hackers > >who can't quite adjust to the power and terseness of C. > > Unfortunately, it's that kind of attitude that leads to the perpetuation of > bad language constructs. Let's keep the blame where it belongs: in letting assignments be expressions. FORTRAN uses `=' for assignment, and nobody ever complained except an occasional mathematician who couldn't understand "I=I+1". = was obviously appropriate, safe, and convenient for a "FORmula TRANslation" language. Personally, I like Modula-2's `#' for .NE. ... but it takes getting used to! -- Col. G. L. Sicherman UU: ...{rocksvax|decvax}!sunybcs!colonel CS: colonel@buffalo-cs BI: csdsicher@sunyabva
aglew@ccvaxa.UUCP (07/16/86)
C assumes the programmer knows what he is doing and lets him do it.
Pascal assumes the programmer does not know what he is doing and
prevents him.
Kind of like Georgia telling you what you can put in your mouth.
Does this mean that C is a language for sodomists?purtill@petrus.UUCP (07/16/86)
>I've been looking at 4.3 code, particularly for the Sun. There are plenty of >places where pointers are used indifferently as pointers to structures and >as pointers to arrays. There is code which relies on ints and pointers being >the same size. There is code which relies on successive declarations being >stored contiguously and in order. All of these are of course nonportable, but.... >Code which relies on NULL equalling zero >is omnipresent. This is perfectly legal. NULL == 0. A null pointer may NOT be 0, but that's the compiler's problem, not yours. When the CONSTANT 0 is converted to a pointer, it has to be changed into a null pointer. This was gone thru in great detail a few months ago. mark purtill (201) 829-5127 ^.-.^ Arpa: purtill@bellcore.com 435 south st 2H-307 ((")) Uucp: ihnp4!bellcore!purtill morristown nj 07960
franka@mmintl.UUCP (07/18/86)
As several people have noted, this discussion has gone on long enough. Part of the problem may be that no one seems willing to state this without also giving their own position on the issue. Let me be the exception. The arguments, both pro and con, have already been given on this issue. Anyone who has not been convinced by your point of view is not going to be convinced by a repetition of the same arguments. So let's drop the topic. Frank Adams ihnp4!philabs!pwa-b!mmintl!franka Multimate International 52 Oakland Ave North E. Hartford, CT 06108
ddb@starfire.UUCP (David Dyer-Bennet) (07/24/86)
> What we really need is a one-character assignment operator; .... > .......................................... The C convention is unfortunate > for two reasons; first, it's unlike everyone else's....................... > C. Wingate Um, actually an early language called Fortran had a one-character assignment operator. Perhaps you've heard of Fortran? I haven't, recently. But anyway, it used the same little ol' character c uses, namely the single equal sign. Seems to me funny assignment operators started with Algol. -- David Dyer-Bennet Usenet: ...ihnp4!umn-cs!starfire!ddb Fido: sysop of fido 14/341, (612) 721-8967 Telephone: (612) 721-8800 USmail: 4242 Minnehaha Ave S Mpls, MN 55406
mouse@mcgill-vision.UUCP (der Mouse) (07/29/86)
In article <2237@brl-smoke.ARPA>, gwyn@BRL.ARPA (VLD/VMB) quotes: >> "I hardly ever get a program to pass through lint without getting >> least a dozen lines of garbage." and writes: > Perhaps "lint" is trying to tell you something. I refuse to cast, for example, printf(), or strcpy(), to void just to keep lint happy. I don't cast normal assignments to void, why should I cast strcpy() (which is conceptually a string assignment)? I refuse to hold with malloc(10) giving a type mismatch error (lint wants unsigned int for the argument). I refuse to listen to possible pointer alignment problems when casting malloc(n) to (struct foo *). C assumes you know what you're doing and lets you do it, wherein lies it power and usefulness. If you want the compiler (typechecker, whatever) to protect you from yourself, use a strongly typed language like Pascal! Don't complain because C isn't the best language for your application; instead, try to pick a more appropriate one. -- der Mouse USA: {ihnp4,decvax,akgua,utzoo,etc}!utcsri!mcgill-vision!mouse think!mosart!mcgill-vision!mouse Europe: mcvax!decvax!utcsri!mcgill-vision!mouse ARPAnet: utcsri!mcgill-vision!mouse@uw-beaver.arpa "Come with me a few minutes, mortal, and we shall talk." - Piers Anthony, Bearing an Hourglass