[comp.lang.c] == vs =

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.)  Pardo

chris@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.)  Pardo

msb@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.edu

franka@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" -me

dkc@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!friedl

flaps@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."