John McCarthy died today.

[Kaz Kylheku]

He must have been waiting to outlive someone who perverted his inventions
with dumb syntax:

(if cond then else) -> cond ? then : else

 

[Nick Keighley]

He must have been waiting to outlive someone who perverted his inventions
with dumb syntax:

  (if cond then else)   ->    cond ? then : else

seems to be a bad month for progammers

 

[Kleuskes & Moos]

He must have been waiting to outlive someone who perverted his
inventions with dumb syntax:

(if cond then else) -> cond ? then : else

Requiescat in Pace.

-------------------------------------------------------------------------------
_____________________________
< I want a WESSON OIL lease!! >
-----------------------------
\
\
___
{~._.~}
( Y )
()~*~()
(_)-(_)
-------------------------------------------------------------------------------

 

[Ben Bacarisse]

He must have been waiting to outlive someone who perverted his inventions
with dumb syntax:

(if cond then else) -> cond ? then : else

How quickly people forget! Originally (cond (c then) (t else)). John
McCarthy might well have considered (if ...) to be a perversion of his
invention!

 

[Ark]

He must have been waiting to outlive someone who perverted his inventions
with dumb syntax:

(if cond then else) -> cond ? then : else

Re dumb syntax - in the eye of the beholder.
The ternary syntax is an /expression/ with type and value and, when used
on (symbolic) constants is indispensable in static initialization, in
particular, of const objects.

 

[Willem]

Ark wrote:
) On 10/24/2011 8:44 PM, Kaz Kylheku wrote:
)> He must have been waiting to outlive someone who perverted his inventions
)> with dumb syntax:
)>
)> (if cond then else) -> cond ? then : else
)
) Re dumb syntax - in the eye of the beholder.
) The ternary syntax is an /expression/ with type and value and, when used
) on (symbolic) constants is indispensable in static initialization, in
) particular, of const objects.

(if cond then else) is *also* an expression with type and value, stupid.


SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT

 

[Phil Carmody]

Ark wrote:
) On 10/24/2011 8:44 PM, Kaz Kylheku wrote:
)> He must have been waiting to outlive someone who perverted his inventions
)> with dumb syntax:
)>
)> (if cond then else) -> cond ? then : else
)
) Re dumb syntax - in the eye of the beholder.
) The ternary syntax is an /expression/ with type and value and, when used
) on (symbolic) constants is indispensable in static initialization, in
) particular, of const objects.

(if cond then else) is *also* an expression with type and value, stupid.

I'm not sure I see anything by Ark that contradicts that, in particular as he
says precisely nothing about the lisp form.

Phil

 

[Keith Thompson]

Ark wrote:
) On 10/24/2011 8:44 PM, Kaz Kylheku wrote:
)> He must have been waiting to outlive someone who perverted his inventions
)> with dumb syntax:
)>
)> (if cond then else) -> cond ? then : else
)
) Re dumb syntax - in the eye of the beholder.
) The ternary syntax is an /expression/ with type and value and, when used
) on (symbolic) constants is indispensable in static initialization, in
) particular, of const objects.

(if cond then else) is *also* an expression with type and value, stupid.

Perhaps you could express technical disagreements without calling
people stupid -- especially in a thread about the death of a
programming language pioneer.

 

[Nick Keighley]

Perhaps you could express technical disagreements without calling
people stupid -- especially in a thread about the death of a
programming language pioneer.

"dumb syntax" wasn'texactly a good start

 

[Ark]

Ark wrote:
) On 10/24/2011 8:44 PM, Kaz Kylheku wrote:
)> He must have been waiting to outlive someone who perverted his inventions
)> with dumb syntax:
)>
)> (if cond then else) -> cond ? then : else
)
) Re dumb syntax - in the eye of the beholder.
) The ternary syntax is an /expression/ with type and value and, when used
) on (symbolic) constants is indispensable in static initialization, in
) particular, of const objects.

(if cond then else) is *also* an expression with type and value, stupid.


SaSW, Willem

A distinction between expression and type-and-value-less statement is a
Good Thing, perhaps contrary to what purists might say. 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. So there, smart Willem.

 

[Kaz Kylheku]

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!

 

[James Kuyper]

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?

 

[Kaz Kylheku]

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) ...)

 

[Keith Thompson]

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.)

 

[James Kuyper]

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.

 

[Kaz Kylheku]

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 +?

 

[BartC]

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.

 

[Charles Richmond]

"-" 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;

 

[Kaz Kylheku]

"-" 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.

 

[James Kuyper]

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.