edw@IUS1.CS.CMU.EDU (Eddie Wyatt) (01/12/88)
I got this letter that I thought I would public reply to. Received: from AMES-NAS.ARPA by IUS1.CS.CMU.EDU; 11 Jan 88 12:32:26 EST Received: Mon, 11 Jan 88 09:30:17 PST by ames-nas.arpa (5.51/1.2) Date: Mon, 11 Jan 88 09:30:17 PST From: Michael S. Fischbein <msf@ames-nas.arpa> Message-Id: <8801111730.AA18470@ames-nas.arpa> To: edw@IUS1.CS.CMU.EDU Subject: Re: (So-Called) ANSI C Newsgroups: comp.lang.c In-Reply-To: <609@PT.CS.CMU.EDU> References: <4668@pyr.gatech.EDU> <495@xyzzy.UUCP> <9930@mimsy.UUCP> <10027@ut-sally.UUCP> Organization: NASA Langley Research Center, Hampton, VA Cc: Status: R In article <609@PT.CS.CMU.EDU> you write: >> Sorry, but in my opinion the similiarity between "==" and "=" is a >>flaw in the language. My attitude towards programming enviroments (languages >>comprise part that) is that one aspect the enviroment should provide is >>assisting programmers in developing software by insolating them against >>common errors they make. >As you say, these are your opinions. They are not facts, nor general >guidelines that I feel compelled to follow. Languages that do a lot >to `insolate' the programmers exist. Try Pascal. C does not do this, >nor, in my opinion and in that of many other programmers, should it. >> Claiming that its the programmer at fault won't, >But the programmer IS at fault. The machine does what you tell it to do, >not what you want it to do. If you can't write a simple routine to >check for = inside if statements, I'll be happy to write it for you. >Then you can check your programs and those of us who don't want to >be warned constantly about perfectly legitimate constructs won't have >to be. You are misreading my article. I do not propose changing the C language nor do I say the compiler should flag this contruct (it is perfectly valid construct for the language which I use myself). The language D should redefine assignment to := then hopefully this type of bug will go away. (ie. we should learn from our mistakes) >> (as in a Venus probe >>that had a bug in the software to the degree: for i=1.100 in Fortran ). >Do you have a reference for this? Or is it as unfounded as the rest of >your posting? O.K. here it is: From "Principles of Programming Languages: Design, Evaluation, and Implementation", Bruce J. MacLennan. pg 90-91 DO 20 I = 1. 100 which looks remarkably like the DO-statement: DO 20 I = 1, 100 In fact, it is an assignment statement to variable called "DO20I", which we can see by rearranging the blanks: DO20I = 1.100 You will probably say that no programmer would ever call a variable "DO20I", and that is correct. But suppose the programmmer intended to type the DO-statemnt above but accidently typed a period instead of a comma (they are next to each other on the keyboard). The statement will have been transformed into an assignment to "DO20I." The programmer will probably not notice the error because "," and "." look so much alike. In fact, there will be no clue that an error has been made because, conveniently, the variable DO20I will be automatically declared. If you think that thing like this can't happen, you will be surprised to learn that an American Viking Venus probe was lost because of precisely this error. BTW those people that claim they don't run into these types of bugs. What do you do all day write your 4 lines of code and that's it? Of course you make sure those lines are bug free. Try producing 400+ line a day. Geez -- Eddie Wyatt e-mail: edw@ius1.cs.cmu.edu
msf@amelia.nas.nasa.gov (Michael S. Fischbein) (01/12/88)
In article <626@PT.CS.CMU.EDU> edw@IUS1.CS.CMU.EDU (Eddie Wyatt) writes: > I got this letter that I thought I would public reply to. >From: Michael S. Fischbein <msf@ames-nas.arpa> >In article <609@PT.CS.CMU.EDU> you write: >>>that had a bug in the software to the degree: for i=1.100 in Fortran ). > >>Do you have a reference for this? > O.K. here it is: >From "Principles of Programming Languages: Design, Evaluation, and >Implementation", Bruce J. MacLennan. pg 90-91 This was gone over in great detail in comp.risks a month or so ago. Of course, I'm SURE that everything in that text is carefully researched and there are absolutely no errors in it, but somehow no one was able find this program. In fact, as was pointed out by a comp.risks contributor, FORTRAN was not used for the probe software; it was all in assembly (check the date, Mr Wyatt). The bug was reported in a newspaper as being a `single character' and, like Parson Weems, a great moral concerning variable names was drawn. It turns out the actual character in error was a `-' and was NOT in the program, but was a logical negation that was overlooked by the programmer translating the symbolic logic into assembly. >BTW those people that claim they don't run into these types of bugs. At least I never said that. Sure, this bites me about once a month. Sometimes I type < instead of <= also. That doesn't mean < should be :< to make all numerical comparisons two characters. mike -- Michael Fischbein msf@prandtl.nas.nasa.gov ...!seismo!decuac!csmunix!icase!msf These are my opinions and not necessarily official views of any organization.
RAY%TEMPLEVM.BITNET@CUNYVM.CUNY.EDU (01/12/88)
Correcting potential bugs is exactly what ANSI and ISO standardization
should attempt to do. I've experience the same problems with == and = as
I used to in COBOL with the period and comma. (my god, he admits to using
COBOL?? :-) Often a hardcopy of a program would be printed with a light
ribbon or mis-alined print hammers and smear commas into periods & vice-
versa. The same could definately happen with the =/==.
Aren't there enough symbols available to use something else for one of these
operators. I fell := would be a much better assignment operator, and I am
NOT a Pascal convert! You could change the equilivance operator, but I
would be at a loss to replace the equals sign with another character, unless
of course, we go the APL way and add a backwards arrow to our keyboards
(APL uses a backarrow for assignment). I pity PC users with a backarrow
on their keyboard which means backspace and a backarrow key for C for
assignments :-)
I do agree that changing the assignment operator to := would be a radical
alteration of the language, causing many programs to require changes, but
why not try to correct potential problems now, before it becomes standard?
Hey, we can always use the global replace in our editors to change == to
:=. Now how hard could that be....?
Ray Lauff ***********************************
Temple University Computer Activity ** Why does it take months to **
Philadelphia, PA ** become proficient at C, yet **
RAY@TEMPLEVM ** it looks so small on a **
** resume next to BASIC? **
***********************************gwyn@brl-smoke.ARPA (Doug Gwyn ) (01/12/88)
In article <11216@brl-adm.ARPA> RAY%TEMPLEVM.BITNET@CUNYVM.CUNY.EDU (Ray Lauff) writes: >I do agree that changing the assignment operator to := would be a radical >alteration of the language, causing many programs to require changes, ... Damn near ALL programs! >why not try to correct potential problems now, before it becomes standard? Because we intend for the standard to be used, not ignored.
V4039%TEMPLEVM.BITNET@CUNYVM.CUNY.EDU (Stan Horwitz) (01/12/88)
Yep, I completely agree with Mr. Lauff who offers some legitimate rationale for having another symbol in place of "==". It is not at all unusual for symbols such as "=" to be misprinted or just smudged on high speed line printers. Why compound errors by having two such similar operators? I suggest the symbol => in place of ==. It's such a nice, unassuming symbol. It's inclusion would not cause many problems even for those compiling older programs. As was said, all that is needed to convert older programs' use of == to => is a global replace command in your editor. If your program is extremely large, then take a few minutes to get a soda while your editor is making the change. We all need an occassional coffee (or soda) break. Stan Horwitz V4039 at TEMPLEVM.BITNET
gwyn@brl-smoke.ARPA (Doug Gwyn ) (01/12/88)
In article <11220@brl-adm.ARPA> V4039%TEMPLEVM.BITNET@CUNYVM.CUNY.EDU (Stan Horwitz) writes: > Yep, I completely agree with Mr. Lauff who offers some legitimate >rationale for having another symbol in place of "==". You guys are just wasting time and net resources carrying on about this. It will not change, and it's been discussed uncountably many times.
pardo@uw-june.UUCP (David Keppel) (01/12/88)
[ replace "==" with "=>" ]
Are you sure you didn't mean ">=" ?-)
(a) "=" vs. "==" can be confusing and buggy.
(b) ":=" for "=" breaks a lot of code.
(c) Nobody is going to change it in C or ANSI-C or C++.
(d) Lint (for those of us who have lint, *sigh*) should complain about
"if (a=b) ..." unless given a comment /*VALTESTED*/ or something.
(e) Compilers should compile programs that have "if (a=b) ...", and any
complaints they generate should be turned off by /*VALTESTED*/.
;-D on (Use lint. Everybody has lots from their clothes dryers.) Pardochris@mimsy.UUCP (Chris Torek) (01/12/88)
In article <3975@uw-june.UUCP> pardo@uw-june.UUCP (David Keppel) writes: >(d) Lint (for those of us who have lint, *sigh*) should complain about > "if (a=b) ..." unless given a comment /*VALTESTED*/ or something. It should (and, with some help from elsie!ado, *does*) complain about if (a = b) ... but not about if ((a = b) != 0) ... -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris
karthur@codas.att.com (Kurt_R_Arthur) (01/12/88)
In article <11220@brl-adm.ARPA> V4039%TEMPLEVM.BITNET@CUNYVM.CUNY.EDU (Stan Horwitz) writes: > > Yep, I completely agree with Mr. Lauff who offers some legitimate > rationale for having another symbol in place of "==". It is not at all > unusual for symbols such as "=" to be misprinted or just smudged on high > speed line printers. Why compound errors by having two such similar > operators? I suggest the symbol => in place of ==. It's such a nice, > unassuming symbol. It's inclusion would not cause many problems even > for those compiling older programs. As was said, all that is needed to > convert older programs' use of == to => is a global replace command in > your editor. If your program is extremely large, then take a few minutes > to get a soda while your editor is making the change. We all need an > occassional coffee (or soda) break. The use of "=>" is troublesome to me for two reasons: 1. It is very similar to the >= operator (not a big deal). 2. It implies assignment from left to right. By this, I mean "a => b" TO ME looks like assign the value of 'a' to 'b'. A better operator (I think) is "<-". It still is similar to other operators (namely "->" & "<="), but it does imply right to left assignment. As far as I'm concerned, the Pascal-type ":=" is not a good choice due to the placement of the ":" and "=" on the keyboard. The actions required to make the combination are awkward for most touch typists. At this late date, though, I'm not sure C will ever change its assignment operator: too much code has been written. This kind of change will almost require a new language. Kurt Arthur Software Services of Florida, Inc.
dag@chinet.UUCP (Daniel A. Glasser) (01/14/88)
In article <11216@brl-adm.ARPA> RAY%TEMPLEVM.BITNET@CUNYVM.CUNY.EDU (Ray Lauff) writes:
'Correcting potential bugs is exactly what ANSI and ISO standardization
'should attempt to do. [stuff about cobol deleted]
'
[more stuff deleted]
'
'I do agree that changing the assignment operator to := would be a radical
'alteration of the language, causing many programs to require changes, but
'why not try to correct potential problems now, before it becomes standard?
'Hey, we can always use the global replace in our editors to change == to
':=. Now how hard could that be....?
'
Actually, you have introduced a bug here -- You are changing comparisons
("==") to assignments (":="). I think that this is all very silly, since
this would change virtually every useful program (I know, there are some
useful programs that make no assignments or comparisons for equality...)
Unless you are using a printer with proportional spacing, '==' does not
look like '=', even with smearing, since the former is much longer than
the latter.
--
Daniel A. Glasser
...!ihnp4!chinet!dag
...!ihnp4!mwc!dag
...!ihnp4!mwc!gorgon!dag
One of those things that goes "BUMP!!! (ouch!)" in the night.jep@oink.UUCP (James E. Prior) (01/18/88)
In article <626@PT.CS.CMU.EDU> edw@IUS1.CS.CMU.EDU (Eddie Wyatt) writes: >I do not propose changing >the C language nor do I say the compiler should flag this contruct >(it is perfectly valid construct for the language which I >use myself). The language D should redefine assignment to >:= then hopefully this type of bug will go away. (ie. we should >learn from our mistakes) >Eddie Wyatt e-mail: edw@ius1.cs.cmu.edu I appreciate the choices that the authors of C made for = and ==. They chose based on which would save them typing. The single '=' was chosen for assignment because assignment is used more than comparison. Comparison got the double '=' pretty much by default. I have no problem distinguishing between = and ==, and don't want to change them at all. Nonetheless I would find changing == much less obnoxious than changing =. Like the authors of C, I find it most important to preserve a single character operator for assignment. I liken == to the very wide symbol used in mathematics a couple hundred years ago to state equality. I do realize that use of == in C for comparison is interragative as opposed to the use of the very wide symbol in ancient math being imperative. Changing == to something else like :: would make sense. I find := for assignment to be quite obnoxious. It's the worst choice I've ever seen. I understand the pressure from other languages that use it, but it is two characters long, misleading, and hideous to look at. In math : is often used for comparison, as in ratios. Using : in := for assignment misleads me to think of comparison instead of assignment. := isn't even pleasing to look at. It's downright ugly. Cyber folklore around the office has it that := originated in Europe as something that looked similar to <=. Their left pointing arrow wasn't a <, it was a legitimate left arrow that matched up with an =. Their left pointing arrow symbol was intuitive and showed the flow of data from the expression on the right side to the variable on the left. When their <= crossed the Atlantic it had to be converted to ASCII. We didn't have the same clean arrow symbol so it somehow got converted to :. We've been suffering with := ever since from a poor translation. I do appreciate the distinction you make between the C language as opposed to 'D'. -- Jim Prior jep@oink.UUCP {ihnp4|cbosgd}!n8emr!oink!jep Pseudo-programmers use pseudo-code to write pseudo-programs on pseudo-machines!
jep@oink.UUCP (James E. Prior) (01/18/88)
In article <11220@brl-adm.ARPA> V4039%TEMPLEVM.BITNET@CUNYVM.CUNY.EDU (Stan Horwitz) writes: > > Yep, I completely agree with Mr. Lauff who offers some legitimate >rationale for having another symbol in place of "==". It is not at all >unusual for symbols such as "=" to be misprinted or just smudged on high >speed line printers. Why compound errors by having two such similar >operators? I suggest the symbol => in place of ==. It's such a nice, >unassuming symbol. Hardly, you claim to be reducing legibility problems by replacing == with =>. However => would suffer from confusion with the structure pointer operator -> and the greater than or equal operator >=. It also isn't intuitive at all. The > in => would be downright misleading in implying that the left operand somehow flows to the right operand. >Stan Horwitz >V4039 at TEMPLEVM.BITNET -- Jim Prior jep@oink.UUCP {ihnp4|cbosgd}!n8emr!oink!jep Pseudo-programmers use pseudo-code to write pseudo-programs on pseudo-machines!
john13@garfield.UUCP (John Russell) (01/19/88)
In article <2111@chinet.UUCP> dag@chinet.UUCP (Daniel A. Glasser) writes: >In article <11216@brl-adm.ARPA> RAY%TEMPLEVM.BITNET@CUNYVM.CUNY.EDU (Ray Lauff) writes: >' >'I do agree that changing the assignment operator to := would be a radical >'alteration of the language, causing many programs to require changes, but > >Actually, you have introduced a bug here -- You are changing comparisons >("==") to assignments (":="). Seems to me that the people who have problems with '=' vs '==' are those who have not come to terms with the implicit comparison with zero done after each operation. I made the = mistake a couple of times very early in the C learning process. But since I convinced myself that "if (x = fn())" was both a valid and useful construct, and put it to use in code, the *meaning* of each has become very apparent so that I use the proper form automatically. People who find the implicit test for zero distasteful (I get the feeling many of them never programmed in assembler) may never be comfortable with '=='. But for people who like it for its conciseness, the chances of using the wrong symbol due to a typo should be no greater than typing "mian" instead of "main". John -- "A Chinese soldier in Tibet who tried to tear off a British woman's Sergeant Bilko T-shirt has become the first known case of someone mistaking Phil Silvers for the Dalai Lama." -- Toronto Globe & Mail, Nov. 14/87
garys@bunker.UUCP (Gary M. Samuelson) (01/20/88)
In article <4403@garfield.UUCP> john13@garfield.UUCP (John Russell) writes: >I made the = mistake a couple of times very early in the C learning process. >But since I convinced myself that "if (x = fn())" was both a valid and >useful construct, and put it to use in code, the *meaning* of each has become >very apparent so that I use the proper form automatically. > >People who find the implicit test for zero distasteful (I get the feeling >many of them never programmed in assembler) may never be comfortable with >'=='. But for people who like it for its conciseness, the chances of using >the wrong symbol due to a typo should be no greater than typing "mian" instead >of "main". 1. I don't find the implicit test for zero "distasteful" -- I find hard-to-read code distasteful. Actually, "taste" is irrelevant. Cost of development and cost of maintenance are. Hard-to-read code costs too much. I enjoy solving puzzles as much as the next guy, but programmers should be paid to write programs, not solve puzzles. 2. It is irrelevant whether I have programmed in assembly. As it happens, I have. I'm very good at it, and I write both assembly and C according to the "write for the reader" principle. 3. I don't buy the "conciseness" argument -- In the first place, 1 character is not significantly more concise than 2. In the second, "conciseness" is only a virtue, in my opinion, to the extent that it provides readability. 4. While it may be true that typing "mian" for "main" is as likely as typing "=" for "==", the linker will tell me that I mispelled "main" by reporting "undefined symbol." Neither the compiler, the linker, nor lint (of which I am an ardent advocate) will tell me if "=" should be "==". 5. When I see "if (x = fn())", I know what it means, but sometimes I am not sure whether the author meant "if (x = fn())" or "if (x == fn())". I spend a lot of time trying to figure out what other programmers meant, even after I figure out what they wrote. "if( (x = fn()) != 0 )" is longer, but it is totally unambiguous to both the author and the (human) reader. Gary Samuelson
franka@mmintl.UUCP (01/23/88)
In article <214@oink.UUCP> jep@oink.UUCP (James E. Prior) writes: >In article <626@PT.CS.CMU.EDU> edw@IUS1.CS.CMU.EDU (Eddie Wyatt) writes: >>The language D should redefine assignment to := then hopefully this type >>of bug will go away. (ie. we should learn from our mistakes) > >Like the authors of C, I find it most important to preserve a single >character operator for assignment. >I find := for assignment to be quite obnoxious. It's the worst choice >I've ever seen. Given the chance to redefine things, I would keep == for comparison exactly as it is. I would also keep = as it is *for the most common kind of comparsion* -- one where the result is not used. I would then introduce a new operator, perhaps :=, for the relatively rare assignment where the result is used. In other words, the type of an expression whose main operator is = is void. This lets us adopt a strict rule that not using an expression whose type is void is an error, without taking anything away from the programmer. (There is something to be said for dropping the := as defined above, so that instead of writing, for example, while ((ch = getchar()) != EOF) ... one would write while ((ch = getchar(), ch) != EOF) .... This gets a little uglier when the expression being assigned into is not a simple variable name, but still not so bad as all that. It will probably lead people to write x = 0; y = 0; instead of a single statement; but this strikes me as a minor point.) -- Frank Adams ihnp4!philabs!pwa-b!mmintl!franka Ashton-Tate 52 Oakland Ave North E. Hartford, CT 06108
garys@bunker.UUCP (Gary M. Samuelson) (01/23/88)
In article <11383@brl-adm.ARPA> dsill@NSWC-OAS.arpa (Dave Sill) writes: >In article <3208@bunker.UUCP> "Gary M. Samuelson" <bunker!garys> writes: >>4. While it may be true that typing "mian" for "main" is as likely as >> typing "=" for "==", the linker will tell me that I mispelled >> "main" by reporting "undefined symbol." Neither the compiler, >> the linker, nor lint (of which I am an ardent advocate) will >> tell me if "=" should be "==". >What `lint' does and what it *should* or *could* do are not the same. >There is no reason why `lint' could not be made to (optionally) >complain about assignments in certain contexts. I think Turbo C >already has this capability. Agreed; now suppose that lint is so changed, and gives me a warning for each occurence of "if( x = y )" -- now what? I *still* have to divine the writer's intent. >In addition, as I've already suggested, a simple "#define EQ ==" >provides another solution to this problem. Agreed; that is another solution to this problem. It's in the same general class as my suggestion -- standardized coding style. >>5. When I see "if (x = fn())", I know what it means, but sometimes I >> am not sure whether the author meant "if (x = fn())" or >> "if (x == fn())". I spend a lot of time trying to figure out >> what other programmers meant, even after I figure out what >> they wrote. "if( (x = fn()) != 0 )" is longer, but it is >> totally unambiguous to both the author and the (human) reader. >I have yet to see an uncontrived situation in which it was hard to >determine which was meant. But if you really want to make it obvious, >how about "if (x = fn(), x)"? It's not as long, is also unambiguous, >and has fewer parens, which I think hinder readability. Current discussions would seem to indicate that the comma operator is a bigger hindrance to readability than parens (which, I agree, can get out of hand). A more serious problem is that 'x' may be a non-trivial expression, involving, for example, pointers, members, and possibly side-effects. 'x' may be a macro; in which case I don't want it evaluated twice. If you consistently use EQ for "==", I will have no difficulty (on this point, at least) reading your code. If I consistently write the explicit test for zero, I don't think you will have difficulty reading mine, either. Actually, instead of the literal '0', I usually use a more meaningful symbol. But that's another topic. Gary Samuelson
andrew@teletron.UUCP (Andrew Scott) (01/26/88)
In article <3208@bunker.UUCP>, garys@bunker.UUCP (Gary M. Samuelson) writes: > When I see "if (x = fn())", I know what it means, but sometimes I > am not sure whether the author meant "if (x = fn())" or > "if (x == fn())". I spend a lot of time trying to figure out > what other programmers meant, even after I figure out what > they wrote. "if( (x = fn()) != 0 )" is longer, but it is > totally unambiguous to both the author and the (human) reader. Not only is the "if ((x = fn()) != 0)" form unambiguous to the human reader, it generates *identical* code as the "if (x = fn())" form does (at least on the compiler I use). It makes a lot sense to make your intentions as a programmer clear to other (future) programmers during the maintenance phase of the software's life cycle, as Gary mentioned in his posting. There is no point in using the shorthand form, unless laziness is a virtue. Andrew Scott -- $ make sense Make: Don't know how to make sense. Stop.
chip@ateng.UUCP (Chip Salzenberg) (01/26/88)
In article <2681@mmintl.UUCP> franka@mmintl.UUCP (Frank Adams) writes: > >I would then introduce a new operator, perhaps :=, for the relatively >rare assignment where the result is used. > >In other words, the type of an expression whose main operator is = is void. This idea is similar to Intel's PL/M (specifically, PL/M-86): Symbol Use Example ------ ------------------- ------------------------------------- = assignment FOO = BAR; = equality IF FOO = BAR THEN CALL BARF(1); := imbedded assignment IF (FOO := BAR) = XYZZY THEN CALL BARF(2); Personally, I dislike PL/M's choice of symbols, which makes imbedded assignment look like a bag off the side of the language -- which, in this case, it is. But maybe ANSI will buy it now that you can show prior art. :-) -- Chip Salzenberg UUCP: "{codas,uunet}!ateng!chip" A T Engineering My employer's opinions are a trade secret. "Anything that works is better than anything that doesn't."
nick@ccicpg.UUCP (Nick Crossley) (01/27/88)
While we are inventing other types of and syntax for assignment, what about the 'displacement' operator which we had in the Algol68C compiler designed by (amongst others) SR Bourne (before he went to Bell to write sh)? This was written ':=:=', and had the same effect as ':=' in that it assigned the value on the right to the variable on the left (loose terminology, I know), but the value of the whole expression was the OLD value of the left hand side, rather than the NEW value as with ':='. This was useful in MANY constructs. One (not very frequent) example is that of swapping two values :- a := b :=:= a; The operate-and-displacement forms were also provided (+:=:=, -:=:=, etc.)
nevin1@ihlpf.ATT.COM (00704a-Liber) (01/28/88)
In article <4439@garfield.UUCP> john13@garfield.UUCP (John Russell) writes: .>In article <3208@bunker.UUCP> garys@bunker.UUCP (Gary M. Samuelson) writes: .>.1. I don't find the implicit test for zero "distasteful" -- I find .>. hard-to-read code distasteful. Actually, "taste" is irrelevant. . .Might I propose a solution then? . .if (q == fn()) /* or if (fn() == q) which some people prefer */ ----------------------^^^^^^^^^^^^^^------------------------------------------ [Note: This is taken slightly out of context.] This type of thing would solve the '= vs. ==' problem. If constants and functions were put on the left side of the equal comparison, the C compiler would usually flag this as an error if '=' were put in place of '==' by mistake. -- _ __ NEVIN J. LIBER ..!ihnp4!ihlpf!nevin1 (312) 510-6194 ' ) ) "The secret compartment of my ring I fill / / _ , __o ____ with an Underdog super-energy pill." / (_</_\/ <__/ / <_ These are solely MY opinions, not AT&T's, blah blah blah
dsill@NSWC-OAS.arpa (Dave Sill) (01/29/88)
In article <558@cerebus.UUCP> Greg Shubin <cerebus!gregs> writes: > brain thinks: "if x is equal to y then ... " brain applies "C-mode" transform to above thought to convert the abstract logical expression to C code. oops, there's a bug in the transform causing ... > fingers type: "if (x = y) ..." instead of "if (x == y) ..." Does it make sense to change the language because some people have a problem making the abstract <=> real transformation? ========= The opinions expressed above are mine. "The limits of my language mean the limits of my world." -- Ludwig Wittgenstein
tainter@ihlpg.ATT.COM (Tainter) (01/30/88)
In article <3519@ihlpf.ATT.COM>, nevin1@ihlpf.ATT.COM (00704a-Liber) writes: >.if (q == fn()) /* or if (fn() == q) which some people prefer */ >-------------------------^^^^^^^^^^^^^^-------------------------------- > [Note: This is taken slightly out of context.] [Note: Taken even further out of context :-) ] > This type of thing would solve the '= vs. ==' problem. If constants and > functions were put on the left side of the equal comparison, the C compiler > would usually flag this as an error if '=' were put in place of '==' by > mistake. But only for constants and functions! Thus it just gives you a false sense of security. > _ __ NEVIN J. LIBER ..!ihnp4!ihlpf!nevin1 (312) 510-6194 --j.a.tainter
ray@micomvax.UUCP (Ray Dunn) (02/01/88)
In article <4403@garfield.UUCP> john13@garfield.UUCP (John Russell) writes: > >Seems to me that the people who have problems with '=' vs '==' are those who >have not come to terms with the implicit comparison with zero done after >each operation. Sorry John, you miss the point completely. The =/== confusion is not for *technical* reasons, it's psychological, or what the programmer *thinks* as he writes = or ==. Remove your heads from the sand, you "holier than thou's" who say "*I* never do that, so it can't be a problem" (not you John). FACT: *MANY* PEOPLE PUT = IN A CONDITIONAL WHEN THEY MEAN ==, IT *IS* A PROBLEM, IT *IS* DIFFICULT TO VISUALLY DETECT, AND IT *DOES* BREAK PROGRAMS, SOMETIMES WITH SERIOUS CONSEQUENCES. The problem has a lot to do with the fact that the "=" symbol universally is referred to as "equals" (:-)! ("equals" does NOT mean "becomes"). The first thing you have to teach a neophyte programmer is that the symbol that he has always used to express an equality is used to represent assignment! It has a lot to do with the fact that most of us use "=" continuously in both senses between conducting our every day lives and while programming. It has a lot to do with the fact that many of us program in several languages, often using "=" to mean "test for equality" in conditionals and booleans, often as well as meaning "becomes" outside that context. It has a lot to do with the fact that "=" as an assignment is allowed and is "useful" in C. Is the confusion clear (:-)? The problem is not the meaning of "==", it is the heavy loading of "=" in the sum of our use and experience with it. 'C' ignores that "=" is already overloaded in the minds of all but those with little experience other than programming in 'C', and allows the thus intrinsically dangerous construct of "=" *NOT* meaning "test for equality" within a conditional! It *IS* a problem, and its resolution belongs in the hands of the "keepers of the language" (currently the Ansi committee). It is their responsibility to address the problem. It is their responsibility to find a solution other than saying "you shouldn't do it"! When the first person is killed by this intrinsically error prone design, who should get sued? (steps down off soapbox to mixed applause and jeers) Ray Dunn. ..philabs!micomvax!ray
noise@eneevax.UUCP (Johnson Noise) (02/01/88)
In article <11523@brl-adm.ARPA> dsill@NSWC-OAS.arpa (Dave Sill) writes: >In article <558@cerebus.UUCP> Greg Shubin <cerebus!gregs> writes: >> brain thinks: "if x is equal to y then ... " > > brain applies "C-mode" transform to above thought to > convert the abstract logical expression to C code. > oops, there's a bug in the transform causing ... > >> fingers type: "if (x = y) ..." instead of "if (x == y) ..." > >Does it make sense to change the language because some people have a >problem making the abstract <=> real transformation? > No. I don't understand what the big problem is about = and ==. I made that mistake once and only once (it took 15 mins. to find it, but I never did it again) when I was still learning the language. If I can remember what to use when, I should think most people can. In fact, one of the main reasons I started using C was the = and not :=. := has got to be the most ugly, most bogus pile of sh*t ever invented, but that's my personal opinion. With all this deal about ANSI and all, most of it is not too dangerous (although I was satisfied with K & R); but if I ever, EVER have to type := I will be very, VERY dissapointed. For the most part, I am (and always will be) an assembly programmer. I thought that most C programmers were. Now it seems that everybody wants in on it and I think the prime directive may be compromised. Sad, isn't it?
news@ism780c.UUCP (News system) (02/03/88)
In article <1202@eneevax.UUCP> noise@eneevax.umd.edu.UUCP (Johnson Noise) writes: > No. I don't understand what the big problem is about = and ==. >I made that mistake once and only once (it took 15 mins. to find it, but >I never did it again) when I was still learning the language. If I can >remember what to use when, I should think most people can. I decided to find out about the = and == problem by looking at an actual program written in C. I counted the number of assignment and equality operations that appeared in the source text of an experimental compiler that I have working on. Below are the statistics: 1455 assigns 422 equality compares 197498 total source characters. Now, if assign required two characters and compare required one, the compiler would have 1033 more characters in its source representation. I am a very slow typist (80 chars/min). Even so, having a two character symbol for assignment operator would have added only about 13 minutes to the total development effort for the compiler. On the other hand, I once received a bug report that was eventually traced to a single = appearing in in a comparison. The program in error was a C compiler! This error caused the compiler to generate a bad code sequence for certain obscure cases (one of the cases appeared in the FORTRAN compiler that was written in C). I leave it to you to guess the cost finding the bug, correcting the C compiler, recompiling every program in the system that had been developed with the compiler, and distributing a corrected system. My conclusion: if = had been chosen for the equality operator and any two character symbol (e.g. ::) had been chosen for the assignment operator, the cost of developing a program in C would be less even though the character count in a program might be 0.5% greater. Marv Rubinstein -- Interactive Systems
trt@rti.UUCP (Thomas Truscott) (02/04/88)
> My conclusion: if = had been chosen for the equality operator and any two > character symbol (e.g. ::) had been chosen for the assignment operator, the > cost of developing a program in C would be less even though the character > count in a program might be 0.5% greater. > Marv Rubinstein -- Interactive Systems The cost of developing a C program would be even less if the compiler (and of course lint) simply pointed out such possible mistakes. No matter what symbols are used for operators, programmers will occasionally use the wrong one. Compilers should warn of possible mistakes such as: if (x = y) foo(); /* :: would be just as dubious */ No matter how well-designed one's indenting style, programmers will occasionally make indenting mistakes. Compilers should warn of dubious indentations, such as: while (foo() > 0); bar(); No matter how clever the operator precedence, programmers will occasionally get unintended precedence. Compilers should warn of hazardous operator usage, such as: i = 1<<n - 1; I do not want special purpose programs to check for these or to rewrite the code. And I strongly prefer these checks to be in the compiler as well as in lint, if only to cut down on the flood of simple programming mistakes that are posted to this newsgroup. (I also think that the cc/lint business needs to be reconsidered.) C compilers already have dozens of warning messages, and they have saved programmers much grief. I see no big issues here, just the details of for what to issue warnings, how to phrase them, and (if it is warranted) how to suppress them. The absence of appropriate warnings is a bug, whether in cc or lint, and should be reported as such. Tom Truscott
broe@ur-tut.UUCP (Eric Brown) (02/04/88)
In article <8836@ism780c.UUCP> marv@ism780.UUCP (Marvin Rubenstein) writes: >My conclusion: if = had been chosen for the equality operator and any two >character symbol (e.g. ::) had been chosen for the assignment operator, the >cost of developing a program in C would be less even though the character >count in a program might be 0.5% greater. > If you think :: for equality would reduce development cost, why don't you: #define :: == Eric.
ix426@sdcc6.ucsd.EDU (Tom Stockfisch) (02/04/88)
In article <2006@rti.UUCP> trt@rti.UUCP (Thomas Truscott) writes: >>[ discussion of =, == confusion] > >The cost of developing a C program would be even less >if the compiler (and of course lint) simply pointed out >such possible mistakes. Lint should do this only with the -h flag. Many people like to get their programs to pass lint without any comment and still use their own idea of style. > Compilers should warn of possible mistakes such as: > if (x = y) foo(); /* :: would be just as dubious */ > > Compilers should warn of dubious indentations, such as: > while (foo() > 0); > bar(); > > Compilers should warn of hazardous operator usage, such as: > i = 1<<n - 1; > I don't mind as long as the warnings are produced ONLY if you specify an extra flag to cc. I don't want any warnings from the compiler if my code is correct, and I don't want to have to conform to some compiler writer's idea of what good style is. C is a free-form input language. If the compiler warns whenever ";" is not followed by newline, then we might as well dump the superfluous ";" and have newline terminate statements. There are times that I don't follow the usual indentation in order to make code clearer. For instance, suppose protect() causes an interrupt handler to be postponed and unprotect() calls the handler if an interrupt occured. Code that shouldn't be interrupted I then write as follows: ... protect(); update_linked_list(); /* note indentation */ get_more_mem_and_save_it(); ... unprotect(); ... Written like this, it is easy to see what code is sensitive and what isn't. I don't want cc complaining here about dubious indentation. >I do not want special purpose programs to check for these or to rewrite >the code. And I strongly prefer these checks to be in the compiler >as well as in lint, if only to cut down on the flood of simple >programming mistakes that are posted to this newsgroup. The only thing that I really would like to be checked by the compiler instead of lint is function argument/return value type mis-matches. But with proposed ANSI function prototypes, compilers will have to do this anyway. >(I also think that the cc/lint business needs to be reconsidered.) In the spirit of unix, each program should do one thing, and do that well. Compilers should compile, and linters should pick lint. >C compilers already have dozens of warning messages, >and they have saved programmers much grief. To reiterate, compilers should not complain about style, only about marginally legal statements. >I see no big issues here, just the details of for what to issue warnings, >how to phrase them, and (if it is warranted) how to suppress them. I don't want messages like warning: your programming style is different from mine warning: code doesn't look exactly like everyone else's unless I explicitly ask for them. -- || Tom Stockfisch, UCSD Chemistry tps@chem.ucsd.edu
pardo@june.cs.washington.edu (David Keppel) (02/05/88)
[ lint should be able to shut up about style ]
In addition to
(a) command line flag to look for indentation problems or not
I would suggest
(b) .lintrc with a description of the preferred style and/or lint comments
at the beginning of the program describing the preferred style
(c) lint comments such as /*LINT NOSTYLE*/ to shut up lint or even
/*LINT INDENT*/ for specific things (like the protect();unprotect();
thing Tom was writing about).
;-D on (Looks good. Try again.) Pardomsb@sq.uucp (Mark Brader) (02/05/88)
All you people arguing about "=" for assignment vs "=" for equality are missing something. The REAL problem is that the people who gave us ASCII thought that a 7-bit character set could be large enough! What is obviously wanted if a natural, 1-character assignment operator *and* a natural, 1-character equality operator. Proof by example: APL. But to achieve a sufficient number of graphic symbols there, they sacrificed the upper-and-lower case distinction. (Some would say APL has too many symbols, but better too many than too few. It still has many fewer than mathematical notation.) Now, could we please get this topic *off* talk.religion.c? If you want a 2-character assignment operator, please go find (or create) another language. Mark Brader, SoftQuad Inc., Toronto, utzoo!sq!msb, msb@sq.com #define MSB(type) (~(((unsigned type)-1)>>1))
grr@cbmvax.UUCP (George Robbins) (02/05/88)
In article <910@ur-tut.UUCP> broe@tut.cc.rochester.edu.UUCP (Eric Brown) writes: > > If you think :: for equality would reduce development cost, why don't you: > > #define :: == For the same reasons one can't #define @ * or #define # & a) it don't work b) many C programmers will think you're weird and say remarkably nasty things about your coding style... -- George Robbins - now working for, uucp: {uunet|ihnp4|rutgers}!cbmvax!grr but no way officially representing arpa: cbmvax!grr@uunet.uu.net Commodore, Engineering Department fone: 215-431-9255 (only by moonlite)
schmidt@gondor.cs.psu.edu (David E. Schmidt) (02/06/88)
>>My conclusion: if = had been chosen for the equality operator and any two >>character symbol (e.g. ::) had been chosen for the assignment operator, ^^^^^^^^^^ >If you think :: for equality would reduce development cost, why don't you: ^^^^^^^^ > >#define :: == Because the C preprocessor would puke on it?
henry@utzoo.uucp (Henry Spencer) (02/07/88)
> To reiterate, compilers should not complain about style, only about > marginally legal statements. The trouble is that the boundary is fuzzy here. Me, I want the compiler to tell me when I've done something wrong and keep quiet when I've done something right, but the definitions of "wrong" and "right" are tricky and not necessarily the same for everyone. What I decided, when faced with a similar situation once, was to have two classes of such messages: warnings and quibbles. Warnings were for things that were likely to be errors; they were on by default but could be turned off. Quibbles were for things that were odd but not necessarily wrong; they were available on request but not by default. The choice *is* a judgement call in some cases, and depends slightly on your user community. > if (x = y) foo(); > > while (foo() > 0); > bar(); > > i = 1<<n - 1; I would class all of these as warnings, because in each case there is a high probability that it is an error. If the bar() were at the same indent level as the while, or the spaces were rearranged properly in the shift example, then they would turn into quibbles. It's quite true that such a set of decisions is, to some degree, a matter of personal style. However, to my dying day I will fight the idiot notion that "there is no such thing as bad style, only different style". All of the above examples are thoroughly bad style, not just different but inferior: they are dangerous, error-prone, hard-to-follow constructs that should be avoided like the plague. Even when the situation is not this extreme, though, there are solid objective arguments for using a standard style in anything that somebody else might have to maintain one day. The phrase "anyone should be able to understand that" is the mark of the amateur, more concerned about his own preferences than his successors' problems. And if the code is strictly private, it's the work of a moment to come up with a shell file that invokes the compiler with warnings suppressed (or grepped out if it comes to that!). -- Those who do not understand Unix are | Henry Spencer @ U of Toronto Zoology condemned to reinvent it, poorly. | {allegra,ihnp4,decvax,utai}!utzoo!henry
wes@obie.UUCP (Barnacle Wes) (02/16/88)
In article <4160@june.cs.washington.edu>, pardo@june.cs.washington.edu (David Keppel) writes: > (c) lint comments such as /*LINT NOSTYLE*/ to shut up lint or even > /*LINT INDENT*/ for specific things (like the protect();unprotect(); > thing Tom was writing about). Actually, the protect(); ... unprotect(); non-problem is simple: protect(); { ... ... } unprotect(); <EOP> (That's an ASCII End-Of-Problem character there). -- /\ - "Against Stupidity, - {backbones}! /\/\ . /\ - The Gods Themselves - utah-cs!utah-gr! / \/ \/\/ \ - Contend in Vain." - uplherc!sp7040! / U i n T e c h \ - Schiller - obie!wes
ray@micomvax.UUCP (Ray Dunn) (02/17/88)
In article <11523@brl-adm.ARPA> dsill@NSWC-OAS.arpa (Dave Sill) writes: >Does it make sense to change the language because some people have a >problem making the abstract <=> real transformation? Yes. Otherwise it will eventually be the cause of someone's death, and that death is avoidable! To others who suggest defining "EQUALS" etc for "==". This is not a solution. The problem is not with the use of "==", the problem is with the use of "=". The solution *has* to involve the "=" operator. It unfortunately cannot be solved without breaking existing code - although only to the extent that syntax errors would be given on existing code by "new" compilers. The "best" solution suggested so far was to disallow "=" in the context of the conditional expression of an if statement, and substitute some other operator, say ":=" (but not necessarily). I do not expect any action will be taken in the current standard wars on this point, it is much too fundamental a problem to be "safely" addressed by the ANSII committee members. It is much easier to disappear into intellectual paroxysms over whether "noalias" actually means "alias" etc. Ray Dunn. ..philabs!micomvax!ray
schmidt@gondor.cs.psu.edu (David E. Schmidt) (02/18/88)
In article <891@micomvax.UUCP> ray@micomvax.UUCP (Ray Dunn) writes: >It *IS* a problem, and its resolution belongs in the hands of the "keepers >of the language" (currently the Ansi committee). It is their responsibility >to address the problem. It is their responsibility to find a solution other >than saying "you shouldn't do it"! Obviously the meaning of "=" can't be changed, but why couldn't the dpANS committee list the operator ":=" as a common extension, where ":=" is in all ways equivalent to "="? (Although it may be preferable to have the result of the assignment be of type void -- I haven't thought about it that much.) Granted it's not the best to have two operators doing the same thing, but it's no fuglier than people defining EQ to ==.
gwyn@brl-smoke.ARPA (Doug Gwyn ) (02/18/88)
In article <3295@psuvax1.psu.edu> schmidt@gondor.cs.psu.edu (David E. Schmidt) writes: >Obviously the meaning of "=" can't be changed, but why couldn't the dpANS >committee list the operator ":=" as a common extension, ... Perhaps they don't want to tell lies. Why are you guys wasting so much effort on a non-problem? If you prefer Pascal, then use it!
karl@haddock.ISC.COM (Karl Heuer) (02/19/88)
In article <3295@psuvax1.psu.edu> schmidt@gondor.cs.psu.edu (David E. Schmidt) writes: >... Why couldn't the dpANS committee list the operator ":=" as a common >extension ...? Maybe because it isn't common. I've never heard of *any* C compiler that accepts it. (If, however, a number of vendors start including this feature, then I think X3J11 would be duty-bound to list it as such, and to consider it for inclusion in the next standard. I hope it doesn't happen.) A better solution would be to list "if (x = y)" and friends as a common warning. There *is* precedent for this, since some versions of lint (and cc too, I'm sure) will flag it. Karl W. Z. Heuer (ima!haddock!karl or karl@haddock.isc.com), The Walking Lint
karl@haddock.ISC.COM (Karl Heuer) (02/20/88)
In article <909@micomvax.UUCP> ray@micomvax.UUCP (Ray Dunn) writes: >To others who suggest defining "EQUALS" etc for "==". This is not a >solution. The problem is not with the use of "==", the problem is with the >use of "=". The solution *has* to involve the "=" operator. If you don't mind the verbosity, you could define "ASSIGN" for "=". >It unfortunately cannot be solved without breaking existing code - although >only to the extent that syntax errors would be given on existing code by >"new" compilers. Well, it doesn't need to be an outright error -- as I mentioned previously, a warning would do it. >The "best" solution suggested so far was to disallow "=" in the context of >the conditional expression of an if statement, and substitute some other >operator, say ":=" (but not necessarily). It's not necessary to create a new operator. If "=" is disallowed in a boolean context, you can write "if ((x = y) != 0)" to get the same effect. It also makes the code more understandable, if you explicitly compare against whichever of { 0, '\0', 0.0, NULL } is appropriate. Btw, the correct spelling is "ANSI", not "ANSII". Karl W. Z. Heuer (ima!haddock!karl or karl@haddock.isc.com), The Walking Lint
dsill@NSWC-OAS.arpa (Dave Sill) (02/20/88)
In article <909@micomvax.UUCP> Ray Dunn <micomvax!ray> writes: >In article <11523@brl-adm.ARPA> dsill@NSWC-OAS.arpa (Dave Sill) writes: >>Does it make sense to change the language because some people have a >>problem making the abstract <=> real transformation? > >Yes. Otherwise it will eventually be the cause of someone's death, and that >death is avoidable! Yeah, like by using competant C programmers. >To others who suggest defining "EQUALS" etc for "==". This is not a >solution. The problem is not with the use of "==", the problem is with the >use of "=". The solution *has* to involve the "=" operator. How so? If style guidelines require the use of EQUALS or EQ instead of == in conditional contexts, = operators will be obvious an unambiguous. (Of course, you could always do "#define IS =" :-) >I do not expect any action will be taken in the current standard wars on >this point, it is much too fundamental a problem to be "safely" addressed by >the ANSII committee members. It is much easier to disappear into >intellectual paroxysms over whether "noalias" actually means "alias" etc. It's beyond the scope of X3J11 (an ANSI, not ANSII or ASCII, committee) to "fix" things such as this. Their task is to codify existing practice, not to design some new language. (Of course some would argue that function prototypes, `noalias', `const', `volatile', parenthesis honoring, et cetera, are not existing practice in C, but that's another thing...) Face the facts: this is C we're talking about, and in C the assignment operator is "=" and the logical equivalence operator is "==". Like it or lump it. It will never change. ========= The opinions expressed above are mine. "A person gets from a symbol the meaning he puts into it, and what is one man's comfort and inspiration is another's jest and scorn." -- Robert Jackson
fujiirm@yendor.UUCP (Roger Fujii) (02/20/88)
In article <909@micomvax.UUCP>, ray@micomvax.UUCP (Ray Dunn) writes: > In article <11523@brl-adm.ARPA> dsill@NSWC-OAS.arpa (Dave Sill) writes: > >Does it make sense to change the language because some people have a > >problem making the abstract <=> real transformation? > > Yes. Otherwise it will eventually be the cause of someone's death, and that > death is avoidable! This argument is doesn't work. There is a BETTER chance of killing someone if you CHANGE the language ("Oh, How was I supposed to know you were going to use an OLD compiler where the = meant something else"). Changing the language defeats one of C's strong points - portability. > To others who suggest defining "EQUALS" etc for "==". This is not a > solution. The problem is not with the use of "==", the problem is with the > use of "=". The solution *has* to involve the "=" operator. It > unfortunately cannot be solved without breaking existing code - although > only to the extent that syntax errors would be given on existing code by > "new" compilers. "Solution" implies there is a problem with the language. I state that the problem is with the USER. Follow the following example: C is the *FIRST* language that you learn. For a "pure" novice (one who has NOT been tainted with Fortran, BASIC.....), the =/== will have clear, distinct and sensible meanings (except for the occasional typo, which is easier to find than a mistyped number - ah, you're going to redefine numbers now.... :-). > > The "best" solution suggested so far was to disallow "=" in the context of > the conditional expression of an if statement, and substitute some other > operator, say ":=" (but not necessarily). > Good, so ban cars that go faster than 20 mph because some people can't handle that speed. The whole point is this: C is fairly consistant (I don't want to hear about <<,>>). Changing the =/== in C is like changing forth to compute numbers using the order of operations (slight :-) overexaggeration, but you get the point). C is a powerful language, and it derives its power by being "close" to the machine. This necessarily implies that it can also be very DANGEROUS if used carelessly (as with any other powerful things). *** C IS NOT A LANGUAGE FOR NOVICES *** If you expect C to protect you from what you are telling it to do, you are not being realistic. Now, I am sure that you won't find too many complaints if you GIVE a compiler a flag to *warn* you if you do assignments in ifs (cc -trainingwheels hello.c), but this should only be a diagnostic tool. The =/== does function and is consistent. Remember the old saying - If it ain't broke, don't fix it. -- Roger Fujii - ACT, Reston, VA Phone: (703)471-9433 Internet: fujiirm@cml.rpi.edu UUCP: ..!{mimsy,sundc}!{prometheus,hqda-ai}!yendor!fujiirm
ok@quintus.UUCP (Richard A. O'Keefe) (02/20/88)
While I can't bring myself to *like* the way C uses '=' to mean assignment (I mean, this is like using '+' to mean "call") I can live with it for a very simple reason: there are *lots* of programming languages other than C which do it. BASIC, COBOL, FORTRAN, PL/I, SNOBOL, ... PL/I is even worse than C, it *also* uses '=' for equality. C PL/I x = y = 0; x, y = 0; x = y == 0; x = y = 0; What is particularly galling is that BCPL used ":=" for assignment and "=" for equality, so the changeover must have been a deliberate choice of the more risky form. There isn't a snowball's chance that this aspect of C will be changed. And if it should be changed, then so should BASIC, COBOL, FORTRAN, PL/I, the Bourne shell, the C shell, and numerous others be changed. If you are concerned about it, it is trivially easy to write a preprocessor that scans a source file, replacing ":=" by "=" and reporting every solitary "=" as an error. (I've done it. Haven't used it in years.) That lint modification sounds even better. Anyone writing programs where human life is at stake should be using some other language than C, some very simple language where the emphasis has been on debugging, verifying, and understanding. (I'm afraid that ADA and Fortran 8X are on the wrong side of the complexity barrier for me.) That very simple language might very well be a subset of C, or mapped onto C. There is one very important thing which the ANSI C standard will buy us. It will now be possible for someone to write a portable "lint"; I am sick of not being about to check the CMS or VMS versions of my programs. This will make up for a lot of the remaining flaws in C, just as the PORT checker made up for a lot of the problems in Fortran. We've recently encountered -- checking printf() & friends -- checking for if (.. = ..) -- generating dANS prototypes from old code as desirable features of "new lint". What else can comp.lang.c readers come up with?
winterss@psu-cs.UUCP (Stafford Winters ) (02/22/88)
I would be inclined to write a secondary preprocessor, that can be invoked
by make, that would substitute == for each = and = for each := which would
allow each programmer to deal with that situation as they saw fit.
Note: this can be accomplished with a macro, but would require inclusion in
each program, which is undesirable.
______
/ /
--/ __. __/
(_/ (_/|_(_/_ Tad Winters
winterss%psu-cs.cs.pdx.edu or winters%jacobs.cs.orst.edufranka@mmintl.UUCP (Frank Adams) (02/22/88)
In article <7273@brl-smoke.ARPA> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes: >Why are you guys wasting so much effort on a non-problem? >If you prefer Pascal, then use it! It isn't a non-problem, and we don't prefer Pascal. For every problem with C, there is a problem 3 times as severe with Pascal. That is no reason not to try to fix the problems with C. -- Frank Adams ihnp4!philabs!pwa-b!mmintl!franka Ashton-Tate 52 Oakland Ave North E. Hartford, CT 06108
schmidt@gondor.cs.psu.edu (David E. Schmidt) (02/25/88)
>Remember the old saying - If it ain't broke, don't fix it.
An unfortunate attitude. Better to say "If it ain't broke, try to improve it."ray@micomvax.UUCP (Ray Dunn) (02/25/88)
In article <1202@eneevax.UUCP> noise@eneevax.umd.edu.UUCP (Johnson Noise) writes: >...If I can >remember what to use when, I should think most people can. The unfortunate thing about people who write statements like that is that they have NO idea just how niavely arrogant they are! The real world is diametrically opposite to the opinion expressed above. Because I am like I am has NO bearing whatsoever on what you or anyone else is/should be, and vice verca. GROW UP PLEASE. Follow-ups to alt.flame. Ray Dunn. ..philabs!micomvax!ray
cik@l.cc.purdue.edu (Herman Rubin) (02/25/88)
In article <2727@mmintl.UUCP>, franka@mmintl.UUCP (Frank Adams) writes: > In article <7273@brl-smoke.ARPA> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes: > >Why are you guys wasting so much effort on a non-problem? > >If you prefer Pascal, then use it! > > It isn't a non-problem, and we don't prefer Pascal. For every problem with > C, there is a problem 3 times as severe with Pascal. That is no reason not > to try to fix the problems with C. > -- > > Frank Adams ihnp4!philabs!pwa-b!mmintl!franka > Ashton-Tate 52 Oakland Ave North E. Hartford, CT 06108 I agree completely. Those who say "FORTRAN can do this, so use FORTRAN" or the same for LISP, etc., are ignoring the problem. I am using C for _numerical_ programming because many of the things I want to use, such as pointers, are not available elsewhere. I believe that, at present, C is the only existing language which allows the programmer to reasonably efficiently use _some_ of the power of the machine; I cannot expect a language designer to be so omniscient that my needs can be anticipated. The intelligent programmer should be able to start with a problem and with the capabilities of the machine on which the problem is to be implemented and be able to implement the derived solution with reasonable ease. At present, C comes closest to doing this. Assembler allows good implementation, but has an unnecessarily complicated syntax, and is totally non-portable. I believe it is possible to achieve good semi-portable code, frequently with a choice of procedures for accomplishing the goal. Telling me that what I want to do in part of my code can be done in FORTRAN, another part in PASCAL, another part in ..., where each part is a small number of lines, is stupid. I do not know of any way to combine anything smaller than subroutines from different compilations, and C suffers from not allowing the user to suggest or even force inline code, which frequently is far faster than a subroutine call and may even take less space in the main program than the subroutine call and subsequent handling of the return. Do not restrict the programmer! -- Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907 Phone: (317)494-6054 hrubin@l.cc.purdue.edu (ARPA or UUCP) or hrubin@purccvm.bitnet
tim@amdcad.AMD.COM (Tim Olson) (02/25/88)
In article <3311@psuvax1.psu.edu> schmidt@gondor.cs.psu.edu (David E. Schmidt) writes: | >Remember the old saying - If it ain't broke, don't fix it. | | An unfortunate attitude. Better to say "If it ain't broke, try to improve it." I think Tom Peters ("In Search of Excellence"?) said something to the effect that it is a great waste of time and manpower to continue to "tweek" and refine things that already work, when there are so many other important things that *don't* work. To paraphrase, "If it ain't broke, find something else to fix." -- Tim Olson Advanced Micro Devices (tim@amdcad.amd.com)
chip@ateng.UUCP (Chip Salzenberg) (02/26/88)
In article <909@micomvax.UUCP> ray@micomvax.UUCP (Ray Dunn) writes: >In article <11523@brl-adm.ARPA> dsill@NSWC-OAS.arpa (Dave Sill) writes: >>Does it make sense to change the language because some people have a >>problem making the abstract <=> real transformation? > >Yes. Otherwise it will eventually be the cause of someone's death, and that >death is avoidable! Enough, already! Before continuing to flame pointlessly about the design of a well-established language like C in an attempt to make it "safe", please commit this quote to memory: "There never has been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code." -- Lawrence Flon And while you're at it, try this (inexact) quote from Peter Norton: "C is an industrial-strength language. What some people seem to forget is that `industrial-strength' also means `not safe for pets or small children'." Or novice programmers, for that matter. -- Chip Salzenberg UUCP: "{codas,uunet}!ateng!chip" A T Engineering My employer's opinions are a trade secret. "Anything that works is better than anything that doesn't."
gwyn@brl-smoke.ARPA (Doug Gwyn ) (02/28/88)
In article <687@l.cc.purdue.edu> cik@l.cc.purdue.edu (Herman Rubin) writes: >Telling me that what I want to do in part of my code can be done in >FORTRAN, another part in PASCAL, another part in ..., where each part >is a small number of lines, is stupid. I suppose it would be -- who is telling you to do that? >Do not restrict the programmer! C's use of = for assignment and == for comparison does not restrict the programmer.
ray@micomvax.UUCP (Ray Dunn) (03/09/88)
I assume everyone still remembers this discussion, my systems news processing is so behind that......anyway.... In article <7273@brl-smoke.ARPA> gwyn@brl.arpa (Doug Gwyn) writes: >Why are you guys wasting so much effort on a non-problem? >If you prefer Pascal, then use it! Doug, did it ever enter your head that so much effort is being "wasted" because we "guys" *dont* think it is a non-problem. We dont prefer Pascal. We *do* prefer C. We believe the use of the "=" operator in C, in conditionals, in the real world context of its many meanings in many uses, is dangerous and error prone. We believe that you should put a safety cage over a spinning gear, not just put up a sign saying "Don't slip on the wet floor into this dangerous device". In <11915@brl-adm.ARPA> dsill@NSWC-OAS.arpa (Dave Sill) suggests that the answer is "using competant [sic] C programmers". This attitude, as well as being incompetently arrogant, just fails to recognize the realities of life. This attitude is one that leads to format commands being "designed" that allows an "incompetent" user, through a slip of the fingers, to wipe his hard disk! What he is directly saying, for example, is: ...that lint is unnecessary, we should rely on the competence of the programmer and not use lint. ...that we should rely on his own (in)ability to spell rather than attempt to define a spelling methodology that would avoid him making errors [I don't believe in spelling wars, but this was too relevant to avoid]. ...that the recent language extensions which, for example, allow parameter type specifications, are unneccessary because we should rely on the programmer to always give the correct argument types to function calls! Dave, don't you believe in removing from system designs, as much of the human ability to make mistakes as possible? > Like it or lump it. It will never change. Dave, the beauty of making statements like this and acting on them, is that you will always be right! It is wonderfully self fulfilling. You'll never achieve anything of course, but you'll always be right! Remember me the next time you discover a "stupid" error in the code you are writing, or when a typo costs you a couple of days work, or a poorly designed user interface costs you a bonus! All of these could be avoided if you were competent in handling them! Followups should perhaps be sent to alt.flame, you will notice the complete absence of smiley faces (or is that spelt faeces)? Ray Dunn. ..{philabs, mnetor, musocs}!micomvax!ray
mouse@mcgill-vision.UUCP (der Mouse) (03/10/88)
In article <502@psu-cs.UUCP>, winterss@psu-cs.UUCP (Stafford Winters ) writes: > I would be inclined to write a secondary preprocessor [...] that > would substitute == for each = and = for each := If you really want = and :=, I would recommend using Pascal. If you must use C for some reason, this is the way to do it. But don't expect me to work on the resulting code. > Note: this can be accomplished with a macro, How? Try it. If you get it to work, I really want to know what macros you used. (I will almost certainly claim that your C compiler is broken, too.) der Mouse uucp: mouse@mcgill-vision.uucp arpa: mouse@larry.mcrcim.mcgill.edu
dsill@NSWC-OAS.arpa (Dave Sill) (03/10/88)
In article <931@micomvax.UUCP> Ray Dunn <micomvax!ray> writes: >I assume everyone still remembers this discussion, my systems news >processing is so behind that......anyway.... I'm sure they wish they could forget it by now. >In <11915@brl-adm.ARPA> dsill@NSWC-OAS.arpa (Dave Sill) suggests that the >answer is "using competant [sic] C programmers". > >This attitude, as well as being incompetently arrogant, just fails to >recognize the realities of life. Yeah, right, and it's realistic to expect something as fundamental as the assignment operator to be changed at this point. That remark *was* flippant, for which I apologize. >What he is [indirectly] saying, for example, is: > >...that lint is unnecessary, we should rely on the competence of the >programmer and not use lint. Not at all true. I'm a firm believer in `lint'. If you want to make your `lint' complain about "=" in conditional contexts, that's fine with me. I don't think you should expect the language to be changed just because you and a few others want it to. >>...that we should rely on his own (in)ability to spell rather than attempt >to define a spelling methodology that would avoid him making errors [I don't >believe in spelling wars, but this was too relevant to avoid]. Yes, a perfect example! I misspelled "competent", a common enough mistake, but you don't hear me saying we should change the spelling of "competent" to "competant", do you? It's just more trouble than it's worth, even if many people make the same mistake. [As an aside, I *do* have a spelling methodology. I run `ispell' on all my postings. I fixed the misspelled "competent", but overwrote the fixed version when I went back into emacs to make other changes.] >...that the recent language extensions which, for example, allow parameter >type specifications, are unneccessary [sic] because we should rely on the >programmer to always give the correct argument types to function calls! I've said it before: I think function prototypes are A Good Thing. I just don't think they should have been added to C. C + x != C, where x = {function prototypes, honored parentheses, et cetera}. >Dave, don't you believe in removing from system designs, as much of the >human ability to make mistakes as possible? Absolutely. But I also realize that some things are just too hard to change. The way to fix them is to design a new system without them (hint: what comes after C?). >> Like it or lump it. It will never change. > >Dave, the beauty of making statements like this and acting on them, is that >you will always be right! It is wonderfully self fulfilling. You'll never >achieve anything of course, but you'll always be right! I'm not being stubborn or arrogant, I'm being pragmatic. >Remember me the next time you discover a "stupid" error in the code you are >writing, or when a typo costs you a couple of days work, or a poorly >designed user interface costs you a bonus! All of these could be avoided if >you were competent in handling them! How many times can *you* use "competent" in one message? >Followups should perhaps be sent to alt.flame, you will notice the complete >absence of smiley faces (or is that spelt faeces)? I think that's "feces". :-) I also think we should drop this discussion from comp.lang.c, but use e-mail if we really must continue it. ========= The opinions expressed above are mine. "I have enough trouble socializing with people. I don't need some object saying `good morning' to me." -- Ted Nelson
ray@micomvax.UUCP (Ray Dunn) (03/14/88)
In article <191@ateng.UUCP> chip@ateng.UUCP (Chip Salzenberg) writes: [ In response to a continuing discussion by myself and others on the = vs == question ] >Enough, already! Before continuing to flame pointlessly about the design >of a well-established language like C in an attempt to make it "safe", Since when was discussing the technical aspects of a language design flaming? Who has decided it is pointless? Only those who disagee that there is a problem? Well-established? I thought the whole point of the current debates was that the language was just about to be poured into the ANSI jello mold, but the flavour nuances had not yet quite been chosen. >please commit this quote to memory: > > "There never has been, nor will there ever be, any programming > language in which it is the least bit difficult to write > bad code." > -- Lawrence Flon Very profound! Very irrelevant, but very profound! (:-) >And while you're at it, try this (inexact) quote from Peter Norton [obviously a major sage of the software industry (:-)]: > "C is an industrial-strength language. What some people seem > to forget is that `industrial-strength' also means `not safe > for pets or small children'." What is being implied here? That no attempt should be made to improve those parts of the langauge which are error prone? Should we not improve the quality of our hard hats just because we are in an "industrial environment". >Or novice programmers, for that matter. Ah! Now I see. We all have to pass a "Salzenberg Test" to be allowed to program in 'C'. Yes, after 23 years in the profession I undoubtably still am a novice in many ways (just think, I've never programmed in COBOL!), however I think I probably could pass *that* test. I have moved Followups to alt.flame, as this posting is no longer discussing the technical aspects! Please continue to post technical points on this subject to comp.lang.c by editing the Followup-To line. Ray Dunn. ..{philabs, mnetor, musocs}!micomvax!ray
chip@ateng.UUCP (Chip Salzenberg) (03/18/88)
[This is _not_ a flame, but it is a response to one.] In article <938@micomvax.UUCP> ray@micomvax.UUCP (Ray Dunn) flames: > [ In response to a continuing discussion by myself and others on the > = vs == question ] >In article <191@ateng.UUCP> chip@ateng.UUCP (Chip Salzenberg) writes: >>Enough, already! Before continuing to flame pointlessly about the design >>of a well-established language like C in an attempt to make it "safe", > >Who has decided it is pointless? Only those who disagee that there is a >problem? > >Well-established? I thought the whole point of the current debates was that >the language was just about to be poured into the ANSI jello mold, but the >flavour nuances had not yet quite been chosen. Sure; but we've long ago agreed to use Jello, not pudding. If you change the usage of = and ==, you don't have C any more. You have a new language. >>And while you're at it, try this (inexact) quote from Peter Norton >[obviously a major sage of the software industry (:-)]: >> "C is an industrial-strength language. What some people seem >> to forget is that `industrial-strength' also means `not safe >> for pets or small children'." > >What is being implied here? That no attempt should be made to improve those >parts of the langauge which are error prone? Should we not improve the >quality of our hard hats just because we are in an "industrial environment". If you were to change = and ==, you would break almost every C program in existence. A compiler modified to reflect such a change would be as useful for compiling C programs as a Fortran compiler! An example: I like C++, and I think that its features enhance software reliability; but I'm not about to call it "C 88". It's a distinct language. C with =/== changed would also be a distinct language. >>Or novice programmers, for that matter. > >Ah! Now I see. We all have to pass a "Salzenberg Test" to be allowed to >program in 'C'. I was not commenting on the skill of those who have posted here. I was disagreeing with the often-espoused idea that language features that make errors possible must be changed, or else we are partially responsible for the errors committed by novice programmers. I believe that there is no such thing as a fool-proof language. If you want a safe language, invent one. When you're done, though, don't call it "C". That name is taken.
mouse@mcgill-vision.UUCP (der Mouse) (03/20/88)
In article <931@micomvax.UUCP>, ray@micomvax.UUCP (Ray Dunn) writes: > I assume everyone still remembers this discussion, [discussion so far has consisted of proposals to change C in various ways, with other people saying the proposed changes are unnecessary] > We believe that you should put a safety cage over a spinning gear, > not just put up a sign saying "Don't slip on the wet floor into this > dangerous device". Except that in this case, it is sometimes useful to slip into the spinning gear, provided you know what you're doing. The cage gets in the way of that. > In <11915@brl-adm.ARPA> dsill@NSWC-OAS.arpa (Dave Sill) [says various > things that Ray takes exception to] > What he is directly saying, for example, is: > [three things, none of which are relevant here] > Dave, don't you believe in removing from system designs, as much of > the human ability to make mistakes as possible? Fine. Let's tie everyone to their bed, so they can't fall down crossing the street and get run over. We need a certain amount of freedom to get things done. My point of view, and apparently that of at least some of the other people here, is that we have to leave the people who do know what they're doing free to do it. I do not think we should throw away lint, for example, because lint doesn't get in my way when I deliberately do something that looks questionable -- it doesn't assume it knows better than I do. > Remember me the next time you discover a "stupid" error in the code > you are writing, or when a typo costs you a couple of days work, > [etc]. And you remember this discussion next time you come up against something your current language won't let you do because its designers considered it a bad thing to do and hence forbade it. Just yesterday I found a bug in some of my code where I'd written == for what I intended to be an assignment. So what? I discover bugs where I've written && instead of ||, too. It's a tradeoff. C chooses freedom, and with it comes the rope to hang yourself. Other languages, such as Pascal, choose safety, but with it comes the restrictions that make it hard to do certain things. I don't believe having both at once is possible, which is why my advice to those who want, say, :=, is "if you want Pascal, use Pascal". der Mouse uucp: mouse@mcgill-vision.uucp arpa: mouse@larry.mcrcim.mcgill.edu
ray@micomvax.UUCP (Ray Dunn) (03/24/88)
In article <1011@mcgill-vision.UUCP> mouse@mcgill-vision.UUCP (der Mouse), obviously feeling cheesed off, squeaks: >In article <931@micomvax.UUCP>, ray@micomvax.UUCP (Ray Dunn) writes: >> We believe that you should put a safety cage over a spinning gear, >> not just put up a sign saying "Don't slip on the wet floor into this >> dangerous device". > >Except that in this case, it is sometimes useful to slip into the >spinning gear, provided you know what you're doing. The cage gets in >the way of that. I agree, it is indeed sometimes useful. Did I make any suggestion anywhere that we remove this ability? I suggest that the safety cage should be the *norm*. Give the guy a wrench if he wants to remove it! Use you incisor teeth on the bars (:-)! But be careful of the cat! >> Dave, don't you believe in removing from system designs, as much of >> the human ability to make mistakes as possible? >Fine. Let's tie everyone to their bed, so they can't fall down >crossing the street and get run over. WOWEE! Is it a bird? Is it a plane? No! Its only *der mouse* taking an incredible unsupported leap from one statement to a conclusion! Can someone please explain the step from question ">>" to conclusion ">"? Or is the tail too long? >> Remember me the next time you discover a "stupid" error in the code >> you are writing, or when a typo costs you a couple of days work, >> [etc]. > >And you remember this discussion next time you come up against >something your current language won't let you do because its designers >considered it a bad thing to do and hence forbade it. > Jeese! You are missing the whole point! Its not the freedom that's bad, its the syntax that's bad! We should all have the right to commit suicide, I would rather not do it accidently (:-)! You *should* be able to do *anything* in a language if you really must. What you should also rely on the language to do is to help you not make stupid mistakes. I make stupid mistakes, you make stupid mistakes, we *all* make stupid mistakes! Stupid mistakes should be *obvious* they should not be *insidious*. >Just yesterday I found a bug in some of my code where I'd written == >for what I intended to be an assignment. So what? I discover bugs >where I've written && instead of ||, too. > So what indeed! Clever little mouse aren't you! At least the majority of us only make stupid mistakes, making *clever* mistakes takes talent! How many have you yet to find, and how many have already done their damage! The cage not only saves *you*, it also saves your poor unsuspecting *users* (or had you forgotten them)? >It's a tradeoff. C chooses freedom, and with it comes the rope to hang >yourself. Or others, as the case may be. Does liking 'C' mean we shouldn't try to improve it? This subject is f***ing demised! It's pushing up the daisies! It's a *dead* subject. It has ceased to 'C'. Ray Dunn. ..{philabs, mnetor, musocs}!micomvax!ray
noise@eneevax.UUCP (Johnson Noise) (03/26/88)
In article <956@micomvax.UUCP> ray@micomvax.UUCP (Ray Dunn) writes: > [ blah, blah ==, =, := blah etc. ] I'm curious, is there anyone other than Ray Dunn that does not like = and == ? As far as I know, he is the only one that complains. If this is the case, I think he should write his own language specification and call it...oh, I don't know...R ? D, RC, RD are not allowed. Why? Oh...I don't know...
dan@lclark.UUCP (Dan Revel) (03/27/88)
I have often thought that it would be nice to have more distinct symbols for = and ==. This thought usually occurs to me sometime after tearing my hair out trying to figure out why the %$#&! computer can't do what it's told. By now I have gotten used to this idiosyncracy and have mades great strides in avoiding premature baldness by looking for this sort of problem first when my programs don't run right... = == := :-) ;^) ? is this evolution?
franka@mmintl.UUCP (Frank Adams) (03/30/88)
In article <1390@eneevax.UUCP> noise@eneevax.umd.edu.UUCP (Johnson Noise) writes: > I'm curious, is there anyone other than Ray Dunn that does >not like = and == ? Let me restate my opinion. I want to keep = and == with almost exactly the same syntax as they have now. The only difference is that = does not have as its value the result of the assignment; instead its value is void. A new operator, perhaps :=, should be introduced, which has exactly the definition that = has now. (However, I would expect a good compiler to complain if the result of the operator is not used, something which cannot (reasonably) be done with the current syntax. This means: (1) We still have the simple, one character operator for the common case. This *is* important. (2) If one miswrites = when one means ==, one gets an error message. (3) The proposal cleans up the semantics by eliminating the category of expressions with a non-void type whose value is commonly ignored. (Mostly -- there still may be functions returning values which are commonly ignored.) This means that a strict compiler can check that a value is used if and only if it is not void. (Casting to void is, of course, permitted.) This could actually be introduced into C over a period of years. The first step is to introduce the new assignment operator, continuing to support use of the result of an = assignment as an obsolete feature. At some later point, this could be phased out. In any event, I would like to see something like this in D (if that ever happens). -- Frank Adams ihnp4!philabs!pwa-b!mmintl!franka Ashton-Tate 52 Oakland Ave North E. Hartford, CT 06108
iwb@lan000.UUCP (04/01/88)
/* Written 4:06 pm Mar 25, 1988 by eneevax.Sun.COM!noise in lan000:comp.lang.c */ In article <956@micomvax.UUCP> ray@micomvax.UUCP (Ray Dunn) writes: > [ blah, blah ==, =, := blah etc. ] I'm curious, is there anyone other than Ray Dunn that does not like = and == ? As far as I know, he is the only one that complains. If this is the case, I think he should write his own language specification and call it...oh, I don't know...R ? D, RC, RD are not allowed. Why? Oh...I don't know... /* End of text from lan000:comp.lang.c */
davidsen@steinmetz.steinmetz.ge.com (William E. Davidsen Jr) (04/02/88)
In the early 70's I designed a language based on B, called IMP. It ran
on the Intel 8080 and GE 600 series, and cross compiled (in both
directions). After talking to a number of people about the readability
of the code, three changes were made in the language:
= was replaced by := to avoid confusion
== was replaced by = since assignment was different
!= was replaced with <> like BASIC
I find it interesting that 15 years later = and == are still biting (or
byting) people and we are still living with it. Perhaps in the next (P)
language this will change.
Disclamer: this is historical fact, not opinion. I have no opinions from
April 1st to Memorial Day.
--
bill davidsen (wedu@ge-crd.arpa)
{uunet | philabs | seismo}!steinmetz!crdos1!davidsen
"Stupidity, like virtue, is its own reward" -medkc@hotlr.ATT (Dave Cornutt) (04/02/88)
In article <2794@mmintl.UUCP> franka@mmintl.UUCP (Frank Adams) writes: > In article <1390@eneevax.UUCP> noise@eneevax.umd.edu.UUCP (Johnson Noise) writes: > > I'm curious, is there anyone other than Ray Dunn that does > >not like = and == ? > I want to keep = and == with almost exactly the same syntax as they have > now. The only difference is that = does not have as its value the result of > the assignment; instead its value is void. A new operator, perhaps :=, > should be introduced, which has exactly the definition that = has now. The only problem that I have with this is that multiple assignments, such as a=b=c=d=e=f=g=0 would become: a:=b:=c:=d:=e:=f:=g:=0 which is harder to type, and somehow not pleasing to my eye. I'm not sure if I'd want to make this change to C. D is another matter; catching the accidental misapplication of "=" in "if" statements would be worth it. -- Dave Cornutt, AT&T Bell Labs (rm 4A406,x1088), Holmdel, NJ UUCP:{ihnp4,allegra,cbosgd}!hotly!dkc "The opinions expressed herein are not necessarily my employer's, not necessarily mine, and probably not necessary"
drl@uunet.UU.NET (David R. Linn) (04/02/88)
Recently, Frank Adams <franka@mmintl.uucp> wrote: >I want to keep = and == with almost exactly the same syntax as they have >now. The only difference is that = does not have as its value the result of >the assignment; instead its value is void. A new operator, perhaps :=, >should be introduced, which has exactly the definition that = has now. and >This could actually be introduced into C over a period of years. The first >step is to introduce the new assignment operator, continuing to support use >of the result of an = assignment as an obsolete feature. At some later >point, this could be phased out. >In any event, I would like to see something like this in D (if that ever >happens). To me, it would seem more appropriate to change the "is-equal-to" operator *in D* from "==" to something like "?=" which 1) emphasizes the "testing nature" of the operator, 2) is less likely to be confused (visually) with the assignment operator, and 3) avoid the situations of having two different assignement operators (one with a value and one without.) The need/desire for an assignment with a value is shown by the two common idioms 1) a = b = c = INIT_VAL; and 2) while ((ch = getchar()) != EOF && ch != '\n') {blah}; Also, by the nature of this response, please note that (I consider that) this dicussion in becoming more D'ish in nature that C'ish. Maybe we need a comp.lang.d/Info-D for these hypothetical discussions. ---------- David Linn ------------------------------------------------- INET: drl@vuse.vanderbilt.edu [129.59.100.1] UUCP: ...!uunet!vuse!drl CSNET: drl@vanderbilt.csnet AT&T: (615)322-7924 BITNET: linndr@vuengvax USPS: P.O. Box 1804, Vanderbilt University, Nashville, TN, USA, 37235
g-rh@cca.CCA.COM (Richard Harter) (04/02/88)
In article <10205@steinmetz.steinmetz.ge.com> davidsen@crdos1.UUCP (bill davidsen) writes: >In the early 70's I designed a language based on B, called IMP. It ran >on the Intel 8080 and GE 600 series, and cross compiled (in both >directions). After talking to a number of people about the readability >of the code, three changes were made in the language: > = was replaced by := to avoid confusion > == was replaced by = since assignment was different > != was replaced with <> like BASIC Jovial also uses <>. This one doesn't matter so much. I've never liked :=. It looks like some kind of baroque smilely face. Oddly enough the fortran solution is, in many ways, the best. (Although one really could do without those dots.) It puts the various symbols in different spaces, and makes = unambigiously assignment. I have never quite understood the conviction on the part of language designers that one has to use <,>, and = for order relationships. One gets the feeling that there are people who feel that if it was done in fortran, it must be, ipso facto, wrong. >I find it interesting that 15 years later = and == are still biting (or >byting) people and we are still living with it. Perhaps in the next (P) >language this will change. Language P omits the equal sign entirely. The P language human factors subcommittee concluded that all usages of = lead to confusion. :-) -- In the fields of Hell where the grass grows high Are the graves of dreams allowed to die. Richard Harter, SMDS Inc.
davidsen@steinmetz.steinmetz.ge.com (William E. Davidsen Jr) (04/06/88)
In article <48100001@lan000> iwb@lan000.UUCP writes: > [...] > I'm curious, is there anyone other than Ray Dunn that does >not like = and == ? As far as I know, he is the only one that >complains. If this is the case, I think he should write his own >language specification and call it...oh, I don't know...R ? > D, RC, RD are not allowed. > Why? Oh...I don't know... I complain! I have been teaching C for five years, as well as using it in projects for work. Incorrect use of = for == is one of the most common errors I see (not that any one error represents more than about 5%, I admit). Morover it shows up more in the code of experienced programmers, because they don'y make as many other mistakes. The problem is not a failure to understand, but a failure in typing, one of of the hardest errors to find. Did you catch the repeated use of "of" above? It's hard to find these things. Will the next language after C be D or P? After all, C came from B, and B was a cut down BCPL... -- bill davidsen (wedu@ge-crd.arpa) {uunet | philabs | seismo}!steinmetz!crdos1!davidsen "Stupidity, like virtue, is its own reward" -me
wes@obie.UUCP (Barnacle Wes) (04/08/88)
In article <226@hotlr.ATT>, dkc@hotlr.ATT (Dave Cornutt) writes: > [...] D is another matter; catching the > accidental misapplication of "=" in "if" statements would be worth it. The one thing that everyone seems to have forgotten in this discussion is that `=' is NOT always invalid in and if clause: volatile short *statreg = (short *) 0x00FFC000L; ... short status; ... if (status = *statreg) { do something with status; } Code like this would (perhaps) be used for polling hardware status registers. Remember, C is supposed to be a general-purpose language! -- /\ - "Against Stupidity, - {backbones}! /\/\ . /\ - The Gods Themselves - utah-cs!utah-gr! / \/ \/\/ \ - Contend in Vain." - uplherc!sp7040! / U i n T e c h \ - Schiller - obie!wes
richardh@killer.UUCP (Richard Hargrove) (04/10/88)
Wow! I've been 'n'ing over this subject for months, now! Is this a new record for beating a subject to death (not to mention wasting net bandwidth)? richard hargrove ----------------
friedl@vsi.UUCP (Stephen J. Friedl) (04/11/88)
< In article <226@hotlr.ATT>, dkc@hotlr.ATT (Dave Cornutt) writes:
< > [...] D is another matter; catching the
< > accidental misapplication of "=" in "if" statements would be worth it.
<
< The one thing that everyone seems to have forgotten in this discussion
< is that `=' is NOT always invalid in and if clause:
Just for the record, some of use both flavors in an |if| test...
{
FILE *fp;
if (fp = fopen(file, "r"), fp == NULL)
{
...
--
Steve Friedl V-Systems, Inc. "Yes, I'm jeff@unh's brother"
friedl@vsi.com {backbones}!vsi.com!friedl attmail!vsi!friedlflaps@utcsri.UUCP (Alan J Rosenthal) (04/11/88)
In article <130@obie.UUCP> wes@obie.UUCP (Barnacle Wes) writes: >The one thing that everyone seems to have forgotten in this discussion >is that `=' is NOT always invalid in an if clause: > > if (status = *statreg) { [ where what is intended is assignment followed by testing of the result ] I think this is better written as "if ((status = *statreg))"; some people even recommend "if ((status = *statreg), status)".% If you write the if as "if (a = b)", many readers of your code (possibly including yourself) will first think "aha, this is a typo". Many other readers will read it as "if (a == b)". It is therefore a good idea to use a visually distinct form. The two forms I list above both result from the idea that `=' should not be the top level operator in a conditional expression. ajr % The semantics of this second version differs from the original if `status' is volatile. If you use volatile in a way that could come up here, you might not want to adopt this second syntax. -- "An aardvark in the nose is worth two in the phototypesetter."