Assignment in test: OK?

[James C Burley]

In article <18326 at ultima.socs.uts.edu.au> jeremy at sinope.socs.uts.edu.au (Jeremy Fitzhardinge) writes:

   >> BTW, if I ever write a new C-like language, ":=" will be the assignment
   >> operator, "==" the comparison operator, and "=" totally invalid!  Although

   If you are going to prevent assignment in a conditional, you are preventing
   it from being an expression.  This stops things like "a=b=c=0;" from falling
   out elegantly.  If you are deadset about making C have the cumbersome expressions
   of pascal, you may as well drop the '++', '+=', '--', '-=' operators, and give
   'and' a higher precidence than everything else (having decided && is too hard
   to type properly).


   --
   Jeremy Fitzhardinge: jeremy at ultima.socs.uts.edu.au  | To make an omelette, you
   No Comment.          jeremy at utscsd.csd.uts.edu.au   | gotta break eggs.
						       |                -J.Stalin

I think I was adequately clear in my original comment.  I said exactly what I
meant: if I was designing a new language to be at a C (or C++) level of
power and expressability, but with no compatibility requirements, I would
specify ":=" as the assignment operator, "==" as the comparison operator,
and make "=" by itself an error (at least as a default; perhaps allow people
to "override" this definition if they want).

I said nothing about disallowing assignment in conditionals.  The fact that I
called ":=" the assignment OPERATOR instead of a flag for an assignment
STATEMENT should have been more than adequate to indicate my intentions.
Put another way, I simply would replace the text "=" for the assignment lexeme
with ":=".  Everything else (how it is used and such) would remain the same.

The point is, casual reading of code containing a mistake like

    if (foo = 0)

compared to an equivalent

    if (foo := 0)

one can easily conclude the mistake is easier to find in the latter case.

I doubt anyone could seriously disagree with an argument that it would have
saved much unnecessary debugging effort if, from the beginning, K&R had
realized that making "=" an assignment OPERATOR (thus allowing it to work as
an operator inside an expression) was a mistake -- it meant they had to make
"==" the comparison operator, which no other language I know of ever had to,
because others do not allow assignment as an operator.  Given that most people
would at one point or another accidentally use "=" instead of "==", it would
have been great (20-20 hindsight) if they'd realized this from the beginning
and made ":=" or some such thing the assignment operator, leaving "=" out of
the picture.  Perhaps C fanatics will disagree with this, but I don't take
seriously people who essentially would say "no, '=' is Right because I'm used
to it" when I'm saying if it had been ':=' from the beginning, THAT is what
we'd all be used to, without having to have gone through RUN-time debugging
to find our early mistakes.  (We'd find most or all of these kinds of bugs at
compile time.)

Then there are those languages that require "=<" instead of "<=" as the
"less than or equals" operator, so they can have "<=" mean something else
(implied-by, or something like that), and I think they are repeating the
same mistake unless they have such strong typing that they'll ALWAYS catch
any case where a programmer forgets and uses "<=" instead of "=<".

James Craig Burley, Software Craftsperson    burley at world.std.com