Path: utzoo!utgpu!water!watmath!clyde!bellcore!faline!sabre!gamma!ulysses!allegra!mit-eddie!husc6!cmcl2!brl-adm!adm!RAY%TEMPLEVM.BITNET@CUNYVM.CUNY.EDU From: RAY%TEMPLEVM.BITNET@CUNYVM.CUNY.EDU Newsgroups: comp.lang.c Subject: Re: == vs = Message-ID: <11216@brl-adm.ARPA> Date: 12 Jan 88 00:24:38 GMT Sender: news@brl-adm.ARPA Lines: 29 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? ** ***********************************