Post without Account — your post will be reviewed, and if appropriate, posted under Anonymous. You can also use this link to report any problems registering or logging in.

Equal versus Equal

  • 1 Replies

Offline Phil

  • Global Moderator
  • Hero Member
  • *****
  • 823
    • View Profile
Equal versus Equal
« March 31, 2017, 01:36:55 PM »
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.
Code: [Select]
if ( a = b )  { simply a shortcut for
Code: [Select]
a = b;
if ( a != 0 ) { ...
Unfortunately, all too often, what you meant to write was a simple test:
Code: [Select]
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:
Code: [Select]
#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:
Code: [Select]
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:
Code: [Select]
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,
Code: [Select]
if ( a := b ) { ...would be quite clearly an assignment of b to a, and the resulting value tested for True or False.
Code: [Select]
if ( a = b ) { ...would still be legal, but there would be a compiler warning (if no #pragma to suppress it).

Code: [Select]
a = b = c;would get a warning (if no #pragma) because it could be a typo for
Code: [Select]
a = b == c;(if the data types permit this). To avoid the warning, you could use
Code: [Select]
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.


Offline sciurius

  • Jr. Member
  • **
  • 67
    • View Profile
    • Website
Re: Equal versus Equal
« Reply #1: April 01, 2017, 07:12:36 AM »
See Niklaus Wirth, "Good ideas, through the looking glass", section 4.1.