«

On 2011-11-04, Ark <> wrote:
> The fact that in
> C (and descendants) the assignment operator is an expression is indeed
> unfortunate and has lead to innumerable bugs stemming from clever
> coding.

This is the consequence of how the operator is spelled, not what kind
of expression it is. Doh!

On 11/04/2011 11:53 AM, Kaz Kylheku wrote:
> On 2011-11-04, Ark <> wrote:
>> The fact that in
>> C (and descendants) the assignment operator is an expression is indeed
>> unfortunate and has lead to innumerable bugs stemming from clever
>> coding.
>
> This is the consequence of how the operator is spelled, not what kind
> of expression it is. Doh!

I thought it was a consequence of the grammar, not the spelling of the
operator. The problem is due entirely to the fact that there is such a
thing in C as an expression that performs assignment, while C has no
such thing as an assignment statement - the closest it comes is an
expression-statement where the relevant expression is an assignment
expression. Those facts are completely independent of the spelling of
the assignment operator.

What alternative spelling for the assignment operator are you
suggesting, that could, without a change to any of the features of the
grammar that I described above, avoid this problem?

On 2011-11-04, James Kuyper <> wrote:
> On 11/04/2011 11:53 AM, Kaz Kylheku wrote:
>> On 2011-11-04, Ark <> wrote:
>>> The fact that in
>>> C (and descendants) the assignment operator is an expression is indeed
>>> unfortunate and has lead to innumerable bugs stemming from clever
>>> coding.
>>
>> This is the consequence of how the operator is spelled, not what kind
>> of expression it is. Doh!
>
> I thought it was a consequence of the grammar, not the spelling of the
> operator. The problem is due entirely to the fact that there is such a
> thing in C as an expression that performs assignment, while C has no
> such thing as an assignment statement - the closest it comes is an
> expression-statement where the relevant expression is an assignment
> expression. Those facts are completely independent of the spelling of
> the assignment operator.

Which problem?

I'm thinking of accidental assignments:

if (defence_condition = UNDER_NUCLEAR_ATTACK)
launch_full_counterstrike();

This problem is caused by the similarity of == and =, but, sure, it would also
go away if you couldn't have an assignment in that context.

Other languages have assignment expressions, but programmers don't make these
mistakes.

;; Lisp

;; actually wanted EQ, but wrote SETF? Vanishingly unlikely.

(when (setf defence-condition :under-nuclear-attack) ...)

Kaz Kylheku <> writes:
> On 2011-11-04, Ark <> wrote:
>> The fact that in
>> C (and descendants) the assignment operator is an expression is indeed
>> unfortunate and has lead to innumerable bugs stemming from clever
>> coding.
>
> This is the consequence of how the operator is spelled, not what kind
> of expression it is. Doh!

If assignment were a statement rather than an expression, then
accidental assignments like:

if (x = y) /* meant to write if (x == y) */

would be caught by the compiler. (Yes, compilers typically warn about
this.)

--
Keith Thompson (The_Other_Keith) kst- <http://www.ghoti.net/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

On 11/04/2011 01:58 PM, Kaz Kylheku wrote:
....
> Which problem?
>
> I'm thinking of accidental assignments:
>
> if (defence_condition = UNDER_NUCLEAR_ATTACK)
> launch_full_counterstrike();
>
> This problem is caused by the similarity of == and =, but, sure, it would also
> go away if you couldn't have an assignment in that context.

And my point is that's the superior solution. Making an assignment an
expression that has a value which can be used in other expressions is a
feature that's seldom taken advantage of, has little to recommend it,
and is frequently misused. The language would be cleaner without it. I
don't feel strongly enough about this point to recommend removing this
feature from any of the several well-established languages that already
has it, but I would recommend not copying that feature in any new languages.
--
James Kuyper

On 2011-11-05, James Kuyper <> wrote:
> On 11/04/2011 01:58 PM, Kaz Kylheku wrote:
> ...
>> Which problem?
>>
>> I'm thinking of accidental assignments:
>>
>> if (defence_condition = UNDER_NUCLEAR_ATTACK)
>> launch_full_counterstrike();
>>
>> This problem is caused by the similarity of == and =, but, sure, it would also
>> go away if you couldn't have an assignment in that context.
>
> And my point is that's the superior solution.

You have to make up your mind what the root cause is of the
=/== mixup bugs. Is it:

a) similarity between = and ==

b) expressions that can contain side effects?

If you say b, but then you redesign the language by only eliminating the plain
assignment operator from expressions, while continuing to allow expressions to
use operators like &= and ++, and to call functions that have side effects,
that is inconsistent with your point! You're then admitting that the side
effects are not really the root cause, just the assignment operator
specifically.

If you believe b) you can make an imperative language in which expressions are
purely functional: no side effects, and calls to pure functions only, not to
procedures.

But it remains that it's the similarity between = and == that leads to
the programming mistake. The programmer did not make some mistake in
the destructive manipulation of data; he didn't even want the expression
to be destructive, but only misspelled the darn operator!

How will you protect the programmer from misspelling one non-destructive
operator for another in a pure expression?

What programming language butchery do you recommend for the situation
when - is written instead of +?

"Kaz Kylheku" <> wrote in message
news:...

> But it remains that it's the similarity between = and == that leads to
> the programming mistake. The programmer did not make some mistake in
> the destructive manipulation of data; he didn't even want the expression
> to be destructive, but only misspelled the darn operator!
>
> How will you protect the programmer from misspelling one non-destructive
> operator for another in a pure expression?
>
> What programming language butchery do you recommend for the situation
> when - is written instead of +?

"-" isn't generally used, in a million other contexts outside of the
language, to mean "+".

In everyday life, "=" *does* usually mean "equals".

So the mistake is simply more likely.

So things can be done about it, such as only allowing (a=b) to return a
value when used on the rhs of another assignment. Or requiring an explicit
operator to extract the value of (a=b). It would be a dramatic change to the
language, but it will never be done because opponents will insist that
anyone who gets = and == mixed up is just a lousy programmer and should be
looking for a simpler occupation.

--
bartc

"BartC" <> wrote in message news:j98dee$fmo$...
> "Kaz Kylheku" <> wrote in message
> news:...
>
>> But it remains that it's the similarity between = and == that leads to
>> the programming mistake. The programmer did not make some mistake in
>> the destructive manipulation of data; he didn't even want the expression
>> to be destructive, but only misspelled the darn operator!
>>
>> How will you protect the programmer from misspelling one non-destructive
>> operator for another in a pure expression?
>>
>> What programming language butchery do you recommend for the situation
>> when - is written instead of +?
>
> "-" isn't generally used, in a million other contexts outside of the
> language, to mean "+".
>
> In everyday life, "=" *does* usually mean "equals".
>
> So the mistake is simply more likely.
>
> So things can be done about it, such as only allowing (a=b) to return a
> value when used on the rhs of another assignment. Or requiring an
> explicit operator to extract the value of (a=b). It would be a dramatic
> change to the language, but it will never be done because opponents will
> insist that anyone who gets = and == mixed up is just a lousy programmer
> and should be looking for a simpler occupation.
>

But assignment *can* be used on the lhs of the statement. See the following
code:

int *a, *b;

a = malloc(sizeof(int));

*(b=a) = 47;

--
+<><><><><><><><><><><><><><><><><><><>+
| Charles Richmond |
+<><><><><><><><><><><><><><><><><><><>+

On 2011-11-07, BartC <> wrote:
> "Kaz Kylheku" <> wrote in message
> news:...
>
>> But it remains that it's the similarity between = and == that leads to
>> the programming mistake. The programmer did not make some mistake in
>> the destructive manipulation of data; he didn't even want the expression
>> to be destructive, but only misspelled the darn operator!
>>
>> How will you protect the programmer from misspelling one non-destructive
>> operator for another in a pure expression?
>>
>> What programming language butchery do you recommend for the situation
>> when - is written instead of +?
>
> "-" isn't generally used, in a million other contexts outside of the
> language, to mean "+".

What if in some insane language, subtraction were written "++" and addition
"+"?

Would you fix the language with some insane restructuring of its fundamental
rules, or would you fix the damn spelling of "++" to "-"?

Being able to identify the true root cause of a problem is indispensable in the
computing business.

> In everyday life, "=" *does* usually mean "equals".
>
> So the mistake is simply more likely.

Here you seem agree with the spelling hypothesis. Since = means equals,
programmers sometimes mistakenly use the wrong operator. If = actually
meant "equals", and assignment was spelled <= or :=, this mistake
would approximately vanish.

> So things can be done about it, such as only allowing (a=b) to return a
> value when used on the rhs of another assignment.

Here, you seem disagree with the spelling hypothesis; it's a deeper problem
related to the context in which = is or is not allowed. We ought to keep the =
operator's spelling as it is, but compensate for it with additional
complications.

> Or requiring an explicit
> operator to extract the value of (a=b). It would be a dramatic change to the
> language, but it will never be done because opponents will insist that

All of those are dramatic changes: changing the spelling of an operator,
or fiddling with various semantic rules.

On 11/07/2011 02:49 PM, Kaz Kylheku wrote:
....
> What if in some insane language, subtraction were written "++" and addition
> "+"?
>
> Would you fix the language with some insane restructuring of its fundamental
> rules, or would you fix the damn spelling of "++" to "-"?

I would not recommend any change to C itself, because the need for
backwards compatibility prevents any meaningful fix to this problem.
Either change would be "insane" because of the huge amount of existing
code that would be broken.

As a feature of a brand new language, I wouldn't characterize the idea
that assignment should be a statement type and not an expression type
insane. It's a normal feature of many existing languages.

I would recommend making BOTH fixes for a new language: the grammatical
one and the spelling one.