On 11/04/2011 01:58 PM, Kaz Kylheku wrote:
...
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 +?