Path: utzoo!attcan!uunet!world!burley From: burley@world.std.com (James C Burley) Newsgroups: comp.lang.c Subject: Re: Assignment in test: OK? Message-ID: Date: 12 Sep 90 11:33:23 GMT References: <1990Sep5.185451.25532@DRD.Com> <928@hls0.hls.oz> <18326@ultima.socs.uts.edu.au> Sender: burley@world.std.com (James C Burley) Organization: The World Lines: 64 In-Reply-To: jeremy@sinope.socs.uts.edu.au's message of 12 Sep 90 02:30:22 GMT In article <18326@ultima.socs.uts.edu.au> jeremy@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@ultima.socs.uts.edu.au | To make an omelette, you No Comment. jeremy@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@world.std.com