CTS logo
hazy blue Catskill Mountains in distance

News:

Give our new Discussions area a try!

PDF::Builder v3.024 Released, 12 September 2022
   Please see the CPAN listing, GitHub entry.

PDF::Table v1.003 Released, 05 July 2022
   Please see the CPAN listing, as well as the GitHub entry.


A Thought…

“politics”, a multi-syllable word from Greek: “poli” meaning many, “tics” meaning blood-sucking parasites.

   — Kinky Freeman

Equal versus Equal

Posted on 2017-Mar-31 at 13:36:55 by Phil

In many C-family languages, it is perfectly acceptable to embed assignments into expressions, as the value of the assignment is available for further use, including testing.

if ( a = b )  { ...

is simply a shortcut for

a = b;
if ( a != 0 ) { ...

Unfortunately, all too often, what you meant to write was a simple test:

if (a == b) { ...

It’s happened to everyone — an equality test that turned into an assignment through a simple typo.

If you run your code through something like lint, such a construction should be flagged as a possible problem, but most people don’t ever use lint, relying on the compiler to warn them about problems. And a = b is as valid as a == b.

During syntactical analysis, it should be possible to determine that the last operation before a test (for if, while, until, etc.) was an assignment, and if so, issue a warning that there might be a typo there. Of course, this will annoy many programmers who like to use such constructs, and will seek a way to shut off the warning. A pragma of some sort might do the job:

#pragma assignment-if-ok
if ( a = b ) { ...

but that’s extra work for the programmer, and clutters up the code.

Some careful coders make it a habit to put simple variables on the right hand side, reducing the chances of an inadvertent assignment:

if ( b+5 == a ) { ...    // is legal
if ( b+5 = a ) { ...  // caught by compiler

However, if both operands are simple variables (eligible for the left hand side of the assignment), this won’t do any good:

if ( a == b ) { ...  // intended
if ( a = b ) { ...  // legal but not what was wanted
if ( b = a ) { ...  // just as bad

What’s to be done? Languages such as Pascal used different tokens for assignment and equality: := for assignment, and = for equality. Are brain checks any harder than with = and ==? Note that = is only one character long, while the other relational operators are two characters long, introducing some possible confusion. Assuming that assignments can still be embedded in expressions (such as for tests), should the compiler always catch the use of = when := was intended (or vice-versa)?

My idea is to allow := in C-family languages as an assignment statement operator, in any place where = is allowed, but possibly a typo for ==. If you use the old-fashioned = in any of those cases, without a #pragma, you’ll get a warning. For example,

if ( a := b ) { ...

would be quite clearly an assignment of b to a, and the resulting value tested for True or False.

if ( a = b ) { ...

would still be legal, but there would be a compiler warning (if no #pragma to suppress it).

a = b = c;

would get a warning (if no #pragma) because it could be a typo for

a = b == c;

(if the data types permit this). To avoid the warning, you could use

a = b := c;

Could other tokens be used beside :=? The first two that come to mind are <- (resembling the APL assignment left arrow) and <=. Many languages already use -> for various structure and class operations, so perhaps <- should be kept in reserve for some operation structure- or class-related, and <= is already “less than or equal” (and => is already used in a number of languages for associative array/hash operations). === is already in use by some languages as “equivalent to” (a stronger match than simply equal values), as is !==.

Would it be good to allow (or even mandate) := universally as a replacement for =? I’m not sure that would cut down on the number of typos, but perhaps someone has studied this and has a more definitive answer. You want to be careful about complicating a language and introducing too many special cases and too much non-orthogonality — themselves a rich source of bugs.


Posted on 2017-Apr-01 at 07:12:36 by sciurius

See Niklaus Wirth, “Good ideas, through the looking glass”, section 4.1.

 

All content © copyright 2005 – 2022 by Catskill Technology Services, LLC.
All rights reserved.
Note that Third Party software (whether Open Source or proprietary) on this site remains under the copyright and license of its owners. Catskill Technology Services, LLC does not claim copyright over such software.

 

This page is https://www.catskilltech.com/equal-versus-equal.html

Search Quotations database.

Last updated Mon, 18 Apr 2022 at 10:23 PM

Valid HTML 5

Sat, 24 Sep 2022 at 5:44 PM EDT