== vs =

[Ray Dunn]

In article <4403 at garfield.UUCP> john13 at 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