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]

seems to be a bad month for progammers

[Kleuskes & Moos]

Requiescat in Pace.

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

[Ben Bacarisse]

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

--
Ben.

[Ark]

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

[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]

Willem <wil...@toad.stack.nl> writes:
> 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
--
Unix is simple. It just takes a genius to understand its simplicity
-- Dennis Ritchie (1941-2011), Unix Co-Creator

[Keith Thompson]

Willem <wil...@toad.stack.nl> writes:
> 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.

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

[Nick Keighley]

On Oct 29, 6:57 pm, Keith Thompson <ks...@mib.org> wrote:
> Willem <wil...@toad.stack.nl> writes:
> > 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.

"dumb syntax" wasn'texactly a good start

[Ark]

On 10/29/2011 1:51 PM, Willem wrote:
> 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]

On 2011-11-04, Ark <akh...@macroexpressions.com> 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!

[James Kuyper]

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]

On 2011-11-04, James Kuyper <james...@verizon.net> wrote:
> On 11/04/2011 11:53 AM, Kaz Kylheku wrote:
>> On 2011-11-04, Ark <akh...@macroexpressions.com> 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) ...)

[Keith Thompson]

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.
--
James Kuyper

[Kaz Kylheku]

On 2011-11-05, James Kuyper <james...@verizon.net> 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 +?

[BartC]

"Kaz Kylheku" <k...@kylheku.com> wrote in message
news:201111042...@kylheku.com...

> 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

[Charles Richmond]

"BartC" <b...@freeuk.com> wrote in message news:j98dee$fmo$1...@dont-email.me...

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 nume...@aquaporin4.com |
+<><><><><><><><><><><><><><><><><><><>+

[Kaz Kylheku]

On 2011-11-07, BartC <b...@freeuk.com> wrote:
> "Kaz Kylheku" <k...@kylheku.com> wrote in message
> news:201111042...@kylheku.com...
>
>> 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.

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

[Keith Thompson]

"BartC" <b...@freeuk.com> writes:
[...]

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

It will never be done because it would break existing code. It has
little or nothing to do with some imagined elitism.

Actually, I can think of a way to address the issue without breaking
existing code. (I don't think this would be adopted, and it probably
wouldn't be worth the added complexity.)

Define ":=" as an alias for "=", the simple assignment operator.
Keep "=" and "==" as they are. Provide an *optional* method
(perhaps a new #pragma) to turn on a warning for any use of "=".

Existing code would be unaffected. New code would be unaffected
if the author doesn't choose to use the new feature.

[BartC]

"Keith Thompson" <ks...@mib.org> wrote in message
news:ln1utje...@nuthaus.mib.org...

> "BartC" <b...@freeuk.com> writes:
> [...]
>> 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).

> Actually, I can think of a way to address the issue without breaking
> existing code. (I don't think this would be adopted, and it probably
> wouldn't be worth the added complexity.)
>
> Define ":=" as an alias for "=", the simple assignment operator.
> Keep "=" and "==" as they are. Provide an *optional* method
> (perhaps a new #pragma) to turn on a warning for any use of "=".
>
> Existing code would be unaffected. New code would be unaffected
> if the author doesn't choose to use the new feature.

Looks good to me. But just surprised you are actually suggesting changing
C's assignment operator to ":=", even if you're making it optional.

The only problems I can see are the confusion when := and = are used in the
same file (because someone using := will be maintaining or reading code that
uses =, and vice versa). And where :=, = and == are allowed at the same
time, people using := are possibly more likely to want to use = for
equality.

--
Bartc

[Kaz Kylheku]

On 2011-11-07, Keith Thompson <ks...@mib.org> wrote:
> "BartC" <b...@freeuk.com> writes:
> [...]
>> 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.
>
> It will never be done because it would break existing code. It has
> little or nothing to do with some imagined elitism.

Of course, there is always the preprocessor.

#define eq(x, y) ((x) == (y))
#define set(x, y) ((x) = (y))

while (!eq(set(ch, get(stream)), EOF)) {
/* ... */
}

[Keith Thompson]

"BartC" <b...@freeuk.com> writes:
> "Keith Thompson" <ks...@mib.org> wrote in message
> news:ln1utje...@nuthaus.mib.org...
>> "BartC" <b...@freeuk.com> writes:
>> [...]
>>> 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).
>
>> Actually, I can think of a way to address the issue without breaking
>> existing code. (I don't think this would be adopted, and it probably
>> wouldn't be worth the added complexity.)
>>
>> Define ":=" as an alias for "=", the simple assignment operator.
>> Keep "=" and "==" as they are. Provide an *optional* method
>> (perhaps a new #pragma) to turn on a warning for any use of "=".
>>
>> Existing code would be unaffected. New code would be unaffected
>> if the author doesn't choose to use the new feature.
>
> Looks good to me. But just surprised you are actually suggesting changing
> C's assignment operator to ":=", even if you're making it optional.

Why is that surprising?

In any case, I'm not advocating it, merely suggesting that it's a
possibility. If we were designing C from scratch today, I'd advocate
using ":=" for assignment. But we're thoroughly stuck with "=" for
assignment. It's tempting to provide a mechanism to use ":=" as an
alternative, but the only thing more confusing than a language that uses
"=" for assignment (and permits it in expressions) is one that uses both
"=" and ":=".

> The only problems I can see are the confusion when := and = are used in the
> same file (because someone using := will be maintaining or reading code that
> uses =, and vice versa). And where :=, = and == are allowed at the same
> time, people using := are possibly more likely to want to use = for
> equality.

*If* we wanted to incrementally replace "=" by ":=" for assignment,
we could have a #pragma that causes ";=" to be recognized and "="
to be forbidden. But the more I think about it, the less I actually
like the idea.

[Keith Thompson]

And of course:

#define BEGIN {
#define END }
#define IF if (
#define THEN } {
#define ELSE } else {
#define ENDIF }

and so on.

[Nick Keighley]

On Nov 7, 8:49 pm, James Kuyper <jameskuy...@verizon.net> wrote:
> 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.

so are assignment expressions

I've always quite liked the idiom

int c;

while ((c = getchar ()) != EOF)
process_char (c);

it often saves clumsy code

int c = getchar ();

while (c != EOF)
{
process_char (c);
c = getchar ();

[Malcolm McLean]

On Nov 8, 12:06 am, Keith Thompson <ks...@mib.org> wrote:
>
> Define ":=" as an alias for "=", the simple assignment operator.
> Keep "=" and "==" as they are.  Provide an *optional* method
> (perhaps a new #pragma) to turn on a warning for any use of "=".
>

Or you could make the warning non-optional.

A utility to go through old C code changing every incidence of "=" to
":=" would be quite simple to write, and would ship with every new
compiler.

--
Basic Algorithms: a "how to" guide for practical programming.
http://www.malcolmmclean.site11.com/www

[James Kuyper]

I use the idiom myself frequently. I like the fact that it allows me to
write only a single call to getchar(). However, I think it is a clumsy
construct.

There's a need I've felt for a long time, and I just realized that
there's a feature that could be defined which would meet that need. I'm
inventing this idea while I'm writing this, so please be patient with
any lack of elegance.

What I want is to define a condition for a looping construct, and two
separate blocks of code that get executed repeatedly until the condition
is met, but the condition is tested between the two blocks, rather than
before or after a single block. It would be sort-of half-way between a
while() and a do-while(). I'm horrible at naming things - I'll just use
"token_n" to indicate the new as-yet unnamed keywords. The grammar
productions for this new kind of iteration statement would be:

token_1 statement_1 while (condition) statement_2 token_2
token_1 declaration while (condition) statement_3 token_2

The semantics would be to execute statement_1 unconditionally, then test
the condition. If the condition is false, terminate the entire
statement. Otherwise, execute the second statement, followed by the
first statement, and test the condition again; repeat until the
condition is false. If the both statements are compound statements, they
are treated as a single block for purposes of scope rules. If
statement_1 is a compound statement, and statement_2 is not, statement_2
is treated for purposes of scope rules as being inside of statement_1's
block. The break and continue statements work exactly as they do in
other iteration statements.

The second grammar rule is treated as being equivalent to

token_1 {declaration} while (condition) statement_3 token_2

The example you gave above could then be written as

token_1
int c = getchar();
while(c != EOF)
process_char(c);
token_2

I would prefer that to either of the alternatives you gave above. Note,
among other things, that the scope of 'c' is restricted to this new
iteration statement, something that's not possible with the other
alternatives.
--
James Kuyper

[James Kuyper]

On 11/07/2011 05:06 PM, Keith Thompson wrote:
...

> Actually, I can think of a way to address the issue without breaking
> existing code. (I don't think this would be adopted, and it probably
> wouldn't be worth the added complexity.)
>
> Define ":=" as an alias for "=", the simple assignment operator.
> Keep "=" and "==" as they are. Provide an *optional* method
> (perhaps a new #pragma) to turn on a warning for any use of "=".

I think it would make more sense for use of "=" to become a syntax error
if that pragma is turned on. That would mandate a diagnostic, but also
give implementations permission to refuse to translate the code.
--
James Kuyper

[BartC]

"Malcolm McLean" <malcolm...@btinternet.com> wrote in message
news:8a3ee570-307b-46b4...@s5g2000vbe.googlegroups.com...

> On Nov 8, 12:06 am, Keith Thompson <ks...@mib.org> wrote:
>>
>> Define ":=" as an alias for "=", the simple assignment operator.
>> Keep "=" and "==" as they are. Provide an *optional* method
>> (perhaps a new #pragma) to turn on a warning for any use of "=".
>>
> Or you could make the warning non-optional.
>
> A utility to go through old C code changing every incidence of "=" to
> ":=" would be quite simple to write, and would ship with every new
> compiler.

Well, every "=" not preceded by "<", ">" and perhaps ":" (where a file has
already been converted), and not followed by another "=".

But what about "=" used to initialise data? Does that also change to ":="?
For a static initialisation, it isn't really assignment.

Or "=" occurring in comments and string literals; sometimes you want these
to be left alone, but if it's commented-out code, or a string literal which
happens to contain C source code, then they need to be changed! Unless it's
C source code intended to produce old-style source...

Or where a "=" occurs in a macro, in a way that would later be matched to
another string to form "<=" or "==".

See, these things are never that easy...

And what about where someone has written a=b when they had actually meant
a==b, but somehow the program works. Once converted to a:=b, it's then less
likely that the error will be spotted later on.

--
Bartc

[lawrenc...@siemens.com]

James Kuyper <james...@verizon.net> wrote:
>
> What I want is to define a condition for a looping construct, and two
> separate blocks of code that get executed repeatedly until the condition
> is met, but the condition is tested between the two blocks, rather than
> before or after a single block. It would be sort-of half-way between a
> while() and a do-while().

That's the generalized do-while loop that I've proposed (not entirely
seriously but not entirely in jest, either) in the past:

do statement1 while ( expression ) statement2

Existing code just uses a null statement for statement2.
--
Larry Jones

I hate it when they look at me that way. -- Calvin

[Phil Carmody]

Kaz Kylheku <k...@kylheku.com> writes:
> On 2011-11-07, BartC <b...@freeuk.com> wrote:
> > "Kaz Kylheku" <k...@kylheku.com> wrote in message
> > news:201111042...@kylheku.com...
> >
> >> 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
> "+"?

Well, there's many a fairly sane language where addition can be
written "- -", why not run with that as an example instead?

[Kaz Kylheku]

On 2011-11-08, James Kuyper <james...@verizon.net> wrote:
> On 11/08/2011 03:38 AM, Nick Keighley wrote:
>> I've always quite liked the idiom
>>
>> int c;
>>
>> while ((c = getchar ()) != EOF)
>> process_char (c);
>>
>> it often saves clumsy code
>>
>> int c = getchar ();
>>
>> while (c != EOF)
>> {
>> process_char (c);
>> c = getchar ();
>> }
>
> I use the idiom myself frequently. I like the fact that it allows me to
> write only a single call to getchar(). However, I think it is a clumsy
> construct.
>
> There's a need I've felt for a long time, and I just realized that
> there's a feature that could be defined which would meet that need. I'm
> inventing this idea while I'm writing this, so please be patient with
> any lack of elegance.

Common Lisp loop macro:

;; pretend (pop *stream*) is analogous to getchar().
(defvar *stream* '(1 2 3 4 5 EOF))

(loop for ch = (pop *stream*) until (eq ch 'EOF) do (print ch))
1
2
3
4
5

The FOR = clause combines initialization and stepping, so the UNTIL test is
interposed in between the first initialization and the first stepping.

You can separate the initialization and stepping using THEN:

;; print powers of two below 100
(loop for x = 1 then (* 2 x) while (< x 100) do (print x))

This suggests a possible extension to C (a backward compatible one).

Suppose the increment could be omitted in the for loop (including the
semicolon)? The initialization could then serve as the increment:

for (ch = getchar(); ch != EOF) {

}

This could even work with:

for (int ch = getchar(); ch != EOF) {

}

The semantics could be that if the step expression is missing, the continuation
of the loop proceeds by re-entering the entire construct, as if by a backwards
goto to a fictitious label:

contin:
for (int ch = getchar(); ch != EOF) {

continue; // goto contin;
}

Another possibility would be that on entry, "int ch = getchar()" behaves
as an initialization, but on subsequent iterations, its behavior turns
into the assignment "ch = getchar()".

The choice would make a semantic difference if C ever gets lexical closures.
Lexical closures could tell the difference between ch being the same object on
every iteration or a newly instantiated binding. Re-using the same variable is
more consistent with imperative iteration.

The problem with all this is syntax: for (A;B) is too similar to for (A;B;)
which already has a meaning. One little semicolon leads to a drastic semantic
change.

What if a keyword were used:

for (int ch = getchar(); ch != EOF; continue) {

}

Nah, way too intuitive!

for (int ch = getchar(); ch != EOF; static) {

}

That's better! :)

[James Kuyper]

...

> What if a keyword were used:
>
> for (int ch = getchar(); ch != EOF; continue) {
>
> }

That would be fine when the first part of the loop is a single
expression statement. It's not greatly dissimilar from the idiom I
already routinely use:

for (int ch; (ch=getchar()) != EOF; )
{
}

In the standard as it's currently written,

for ( clause-1 ; expression-2 ; expression-3 ) statement

clause-1 can be an expression or a declaration; expression-2 and
expression-3 can only be expressions. only the final part is a
statement. What I'm talking about could be implemented through a
modification of the syntax to

for ( clause-1 ; statement-1 expression ) statement-2

This would be backwards-compatible because "expression-2 ;" would
qualify as an expression-statement. Non-trivial wording would have to be
proposed to cover how the loop condition is determined if statement-1 is
anything other than an expression-statement. I'm not going to bother
working out what that wording should be, because I favor doing this as a
modification of the do-while statement, which seems more natural.

[Keith Thompson]

James Kuyper <james...@verizon.net> writes:
[...]

> There's a need I've felt for a long time, and I just realized that
> there's a feature that could be defined which would meet that need. I'm
> inventing this idea while I'm writing this, so please be patient with
> any lack of elegance.
>
> What I want is to define a condition for a looping construct, and two
> separate blocks of code that get executed repeatedly until the condition
> is met, but the condition is tested between the two blocks, rather than
> before or after a single block. It would be sort-of half-way between a
> while() and a do-while(). I'm horrible at naming things - I'll just use
> "token_n" to indicate the new as-yet unnamed keywords. The grammar
> productions for this new kind of iteration statement would be:
>
> token_1 statement_1 while (condition) statement_2 token_2
> token_1 declaration while (condition) statement_3 token_2

while (1) {
int c = getchar();
if (c == EOF) break;
process_char(c);

[James Kuyper]

On 11/08/2011 05:10 PM, Keith Thompson wrote:
> James Kuyper <james...@verizon.net> writes:
> [...]
>> There's a need I've felt for a long time, and I just realized that
>> there's a feature that could be defined which would meet that need. I'm
>> inventing this idea while I'm writing this, so please be patient with
>> any lack of elegance.
>>
>> What I want is to define a condition for a looping construct, and two
>> separate blocks of code that get executed repeatedly until the condition
>> is met, but the condition is tested between the two blocks, rather than
>> before or after a single block. It would be sort-of half-way between a
>> while() and a do-while(). I'm horrible at naming things - I'll just use
>> "token_n" to indicate the new as-yet unnamed keywords. The grammar
>> productions for this new kind of iteration statement would be:
>>
>> token_1 statement_1 while (condition) statement_2 token_2
>> token_1 declaration while (condition) statement_3 token_2
>
> while (1) {
> int c = getchar();
> if (c == EOF) break;
> process_char(c);
> }

OK, so there's no need for a new language feature. I generically dislike
while(1) loops, which is probably why I didn't think of that solution.
I'll keep it in mind for the future.

[Keith Thompson]

Malcolm McLean <malcolm...@btinternet.com> writes:
> On Nov 8, 12:06 am, Keith Thompson <ks...@mib.org> wrote:
>> Define ":=" as an alias for "=", the simple assignment operator.
>> Keep "=" and "==" as they are.  Provide an *optional* method
>> (perhaps a new #pragma) to turn on a warning for any use of "=".
>>
> Or you could make the warning non-optional.
>
> A utility to go through old C code changing every incidence of "=" to
> ":=" would be quite simple to write, and would ship with every new
> compiler.

Are you serious?

Even if I thought it was a good idea, a language change that would
require modifying practically every C source file ever written
would never be accepted.

Modifying source files, even mechanically, is never a zero-cost
operation. Source control systems would show *huge* diffs between
successive versions of the same file. Suppose, for example,
that foo.c version 1 uses "=" for assignment, version 2 makes
some functional changes (10 lines changed), version 3 changes
all the "=" to ":=" (with no other changes), and version 4 makes
some more functional changes (7 lines changed). Imagine trying
to compare versions 1 and 4 to see what the actual changes were.
(No, we're not going to modify every diff tool in existence to
ignore "=" vs. ":=".) And that's assuming the "=" to ":=" change
isn't combined with other modifications.

And version 4 will not compile with earlier compilers. Now that I
think about it, that's a very strong argument against my original
idea.

Using "=" for assignment was not, in my opinion, a good idea. Any
attempt to change it now would be far worse.

[Edward Rutherford]

With this attitude, the language will never improve!

[Joe Wright]

On 11/8/2011 17:10, Keith Thompson wrote:
> James Kuyper<james...@verizon.net> writes:
> [...]
>> There's a need I've felt for a long time, and I just realized that
>> there's a feature that could be defined which would meet that need. I'm
>> inventing this idea while I'm writing this, so please be patient with
>> any lack of elegance.
>>
>> What I want is to define a condition for a looping construct, and two
>> separate blocks of code that get executed repeatedly until the condition
>> is met, but the condition is tested between the two blocks, rather than
>> before or after a single block. It would be sort-of half-way between a
>> while() and a do-while(). I'm horrible at naming things - I'll just use
>> "token_n" to indicate the new as-yet unnamed keywords. The grammar
>> productions for this new kind of iteration statement would be:
>>
>> token_1 statement_1 while (condition) statement_2 token_2
>> token_1 declaration while (condition) statement_3 token_2
>
> while (1) {
> int c = getchar();
> if (c == EOF) break;
> process_char(c);
> }
>

Who are you and what have you done to Keith? He cannot write anything like
this.


--
Joe Wright
"If you rob Peter to pay Paul you can depend on the support of Paul."

[James Kuyper]

On 11/08/2011 05:23 PM, Edward Rutherford wrote:
> Keith Thompson wrote:
...

>> And version 4 will not compile with earlier compilers. Now that I think
>> about it, that's a very strong argument against my original idea.
>>
>> Using "=" for assignment was not, in my opinion, a good idea. Any
>> attempt to change it now would be far worse.
>
> With this attitude, the language will never improve!

Whenever you propose a backwards-incompatible change to the language,
the benefits of the change need to be balanced against the costs due tot
he incompatibility. The change should not be done unless the benefits
outweigh the costs by a substantial margin This constrains the
possibilities for improvement, but it does not prevent improvement.

[Kaz Kylheku]

On 2011-11-08, Edward Rutherford <edward.p.r...@REMOVETHIS.gmail.com> wrote:

> Keith Thompson wrote:
>
>> Using "=" for assignment was not, in my opinion, a good idea. Any
>> attempt to change it now would be far worse.
>
> With this attitude, the language will never improve!

Inextensible languages like C do improve or at least evolve by creating
spin-offs which are new languages. Some are backward-compatible (Objective C).
Some have a lot of backward compatibility (C++). Others are incompatible
(Java).

Speaking of which, even though Java is not meant to be compatible with C, its
assignment operator is = and comparison is ==.

Oops!

[Kaz Kylheku]

On 2011-11-08, James Kuyper <james...@verizon.net> wrote:
> On 11/08/2011 11:48 AM, Kaz Kylheku wrote:
>> This suggests a possible extension to C (a backward compatible one).
> ...
>> }
>

> That would be fine when the first part of the loop is a single
> expression statement.
>

> already routinely use:
>
> for (int ch; (ch=getchar()) != EOF; )
> {
> }

Don't forget C's "other compound statement": the comma operator.

for (int ch; ch = getchar(), ch != EOF; )
{
}

:)

[Kaz Kylheku]

On 2011-11-08, James Kuyper <james...@verizon.net> wrote:

> On 11/08/2011 05:23 PM, Edward Rutherford wrote:
>> Keith Thompson wrote:
> ...
>>> And version 4 will not compile with earlier compilers. Now that I think
>>> about it, that's a very strong argument against my original idea.
>>>
>>> Using "=" for assignment was not, in my opinion, a good idea. Any
>>> attempt to change it now would be far worse.
>>
>> With this attitude, the language will never improve!
>
> Whenever you propose a backwards-incompatible change to the language,

A backwards-incompatible change creates simply creates a new language or
dialect.

> the benefits of the change need to be balanced against the costs due tot
> he incompatibility.

More like, the benefits of the introduction of a language which is not
significantly backward-compatible with anything need to be considered against
the odds of the project failing to captivate anyone's interest, or garnering
outright rejection, which are very likely outcomes no matter how good it is.

[Keith Thompson]

Edward Rutherford <edward.p.r...@REMOVETHIS.gmail.com> writes:
> Keith Thompson wrote:
[...]

>> Using "=" for assignment was not, in my opinion, a good idea. Any
>> attempt to change it now would be far worse.
>
> With this attitude, the language will never improve!

With any other attitude, the language will die.

If you think that changing the C language to use ":=" rather than
for assignment is a good idea, that's not an unreasonable opinion,
at least at first glance. Frankly, I *wish* I could agree. But if
you want to propose such a change and have it taken seriously,
you need to address the problems it could cause (as I did in my
previous message).

So tell us, how would you address the problem of existing code that
uses "=" for assignment, and of new code using ":=" for assignment
that would no longer compile with older compilers? Similarly,
how would you address the legions of C programmers who believe
(rightly or wrongly) that using "=" for assignment and "==" for
equality is ok, and doesn't need to be fixed?

Please be specific.

[Keith Thompson]

Huh? Please elaborate.

[Joe Wright]

while (1) and break; ? Edsger is spinning. Plus it's ugly.

[Nick Keighley]

On Nov 8, 12:05 pm, James Kuyper <jameskuy...@verizon.net> wrote:
> On 11/08/2011 03:38 AM, Nick Keighley wrote:
> > On Nov 7, 8:49 pm, James Kuyper <jameskuy...@verizon.net> wrote:

<snip>

> >> 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.
>
> > so are assignment expressions
>
> > I've always quite liked the idiom
>
> >     int c;
>
> >     while ((c = getchar ()) != EOF)
> >         process_char (c);
>
> > it often saves clumsy code
>
> >     int c = getchar ();
>
> >     while (c != EOF)
> >     {
> >         process_char (c);
> >         c = getchar ();
> >     }
>
> I use the idiom myself frequently. I like the fact that it allows me to
> write only a single call to getchar(). However, I think it is a clumsy
> construct.
>
> There's a need I've felt for a long time, and I just realized that
> there's a feature that could be defined which would meet that need. I'm
> inventing this idea while I'm writing this, so please be patient with
> any lack of elegance.
>
> What I want is to define a condition for a looping construct, and two
> separate blocks of code that get executed repeatedly until the condition
> is met, but the condition is tested between the two blocks, rather than
> before or after a single block.

I use break if I need that control structure

for (;;)
{

c = getchar();
if (c == EOF) break;
process_char (c);
}

of course the structurati will drop on you like tonne of rectilinear,
fired clay building modules.

It also doesn't nest well (ok, i doesn't nest at all)

[Nick Keighley]

On Nov 9, 6:08 am, Joe Wright <joewwri...@comcast.net> wrote:
> On 11/8/2011 19:35, Keith Thompson wrote:
>
>
>

> > Joe Wright<joewwri...@comcast.net>  writes:

> >> On 11/8/2011 17:10, Keith Thompson wrote:

> >>> James Kuyper<jameskuy...@verizon.net>   writes:
> >>> [...]
> >>>> There's a need I've felt for a long time, and I just realized that
> >>>> there's a feature that could be defined which would meet that need. I'm
> >>>> inventing this idea while I'm writing this, so please be patient with
> >>>> any lack of elegance.
>
> >>>> What I want is to define a condition for a looping construct, and two
> >>>> separate blocks of code that get executed repeatedly until the condition
> >>>> is met, but the condition is tested between the two blocks, rather than
> >>>> before or after a single block. It would be sort-of half-way between a
> >>>> while() and a do-while(). I'm horrible at naming things - I'll just use
> >>>> "token_n" to indicate the new as-yet unnamed keywords. The grammar
> >>>> productions for this new kind of iteration statement would be:
>
> >>>>        token_1 statement_1 while (condition) statement_2 token_2
> >>>>        token_1 declaration while (condition) statement_3 token_2
>
> >>> while (1) {
> >>>       int c = getchar();
> >>>       if (c == EOF) break;
> >>>       process_char(c);
> >>> }
>
> >> Who are you and what have you done to Keith? He cannot write anything like
> >> this.
>
> > Huh?  Please elaborate.
>
> while (1) and break; ? Edsger is spinning. Plus it's ugly.

Author of the famous "break Considered harmful"?

[Malcolm McLean]

On Nov 9, 2:34 am, Keith Thompson <ks...@mib.org> wrote:
>
> So tell us, how would you address the problem of existing code that
> uses "=" for assignment, and of new code using ":=" for assignment
> that would no longer compile with older compilers?  Similarly,
> how would you address the legions of C programmers who believe
> (rightly or wrongly) that using "=" for assignment and "==" for
> equality is ok, and doesn't need to be fixed?
>

You need to make the change compulsory, so the Luddites will have to
use old compilers. Otherwise you get a worse mess than the one you
were trying to solve. The new compiler gives an error, "old style
assignment operator: please run makenewstyle". So you type
makenewstyle *.c, and within seconds, all your code compiles.

There are some potential problems with diff and so on. If you've got a
decent version control system then the new code is just flagged as a
"new version", and it's no different to adding a comment, maybe a
copyright notice to comply with new corporate policy. But there will
be people for whom having two logically identical but textually
different source files will be a nuisance. Then for a while there will
be both old and new compilers in existence. You can't break old code
without some problems.

However old code with implict int will generate an unacceptable
cascade of warnings on new compilers. implicit int has just about died
out, together with old style function declarations. Changes are
possible.

[Quentin Carbonneaux]

On 2011-11-09, Nick Keighley <nick_keigh...@hotmail.com> wrote:
> On Nov 8, 12:05 pm, James Kuyper <jameskuy...@verizon.net> wrote:
>> On 11/08/2011 03:38 AM, Nick Keighley wrote:
>> > On Nov 7, 8:49 pm, James Kuyper <jameskuy...@verizon.net> wrote:
>> I use the idiom myself frequently. I like the fact that it allows me to
>> write only a single call to getchar(). However, I think it is a clumsy
>> construct.
>>
>> There's a need I've felt for a long time, and I just realized that
>> there's a feature that could be defined which would meet that need. I'm
>> inventing this idea while I'm writing this, so please be patient with
>> any lack of elegance.
>>
>> What I want is to define a condition for a looping construct, and two
>> separate blocks of code that get executed repeatedly until the condition
>> is met, but the condition is tested between the two blocks, rather than
>> before or after a single block.

Well, this construct is not that new. Knuth, in "Structured Programming
with GOTO Statements" mentioned it as follows:

loop; S; while B; T; repeat;

According to this paper, it was first proposed by Ole-Johan Dahl.
S and T can be empty, so we recover while () {} and do {} while ()
loops.

> I use break if I need that control structure
>
> for (;;)
> {
> c = getchar();
> if (c == EOF) break;
> process_char (c);
> }
>
> of course the structurati will drop on you like tonne of rectilinear,
> fired clay building modules.
>
> It also doesn't nest well (ok, i doesn't nest at all)

Indeed, break does the trick, but some people dislike them...

--
qcar

[Joe Wright]

Edsger Dijkstra, proponent of structured programming.

[Nick Keighley]

yes I know. It was a joke. Referring Dijkstra's famous paper...

[Nick Keighley]

On Nov 9, 11:59 am, Quentin Carbonneaux <qcarb...@invalid.com> wrote:

I consider this quasi-religious. The questions you should be asking is
"does it express the intent clearly?" "is it unnecessarily hard to
understand?". Everythign else is just unnecessary fluff

[Edward Rutherford]

Keith Thompson wrote:
> Edward Rutherford <edward.p.r...@REMOVETHIS.gmail.com> writes:
>> Keith Thompson wrote:
> [...]
>>> Using "=" for assignment was not, in my opinion, a good idea. Any
>>> attempt to change it now would be far worse.
>>
>> With this attitude, the language will never improve!
>
> With any other attitude, the language will die.
>
> If you think that changing the C language to use ":=" rather than for
> assignment is a good idea, that's not an unreasonable opinion, at least
> at first glance. Frankly, I *wish* I could agree. But if you want to
> propose such a change and have it taken seriously, you need to address
> the problems it could cause (as I did in my previous message).
>
> So tell us, how would you address the problem of existing code that uses
> "=" for assignment, and of new code using ":=" for assignment that would
> no longer compile with older compilers? Similarly, how would you
> address the legions of C programmers who believe (rightly or wrongly)
> that using "=" for assignment and "==" for equality is ok, and doesn't
> need to be fixed?
>
> Please be specific.

Python has dealt with this problem very successfully, Kieth: see http://
www.python.org/dev/peps/pep-0005/ for some general approaches, but also
http://docs.python.org/release/3.0/whatsnew/3.0.html for details about
transitioning to "the first ever intentionally backwards incompatible
Python release".

One of the key planks supporting upgrades to Python 3.0 is an automated
conversion tool, 2to3 (http://docs.python.org/release/3.0/
library/2to3.html#to3-reference), which automatically upgrades 2.x source
code to valid 3.0 Python syntax.

It would be a simple matter to write a converter that read a C source
file and replaced all = assignment operators with :=

Incidentally, Python has many convenient features that could easily be
added to C, e.g. multiple comparisons behave correctly (a < b > c etc);
array and string slicing e.g. s[4:7] as a shortcut for strndup(s+4,3);
else clauses on loops; and many more. Unfortunately the current fashion
seems to be to try to preserve C in aspic.

[BartC]

"Edward Rutherford" <edward.p.r...@REMOVETHIS.gmail.com> wrote in
message news:j9eceq$jb3$1...@speranza.aioe.org...

> Keith Thompson wrote:

>> So tell us, how would you address the problem of existing code that uses
>> "=" for assignment, and of new code using ":=" for assignment that would
>> no longer compile with older compilers? Similarly, how would you
>> address the legions of C programmers who believe (rightly or wrongly)
>> that using "=" for assignment and "==" for equality is ok, and doesn't
>> need to be fixed?
>>
>> Please be specific.
>
> Python has dealt with this problem very successfully, Kieth: see http://
> www.python.org/dev/peps/pep-0005/ for some general approaches, but also
> http://docs.python.org/release/3.0/whatsnew/3.0.html for details about
> transitioning to "the first ever intentionally backwards incompatible
> Python release".
>
> One of the key planks supporting upgrades to Python 3.0 is an automated
> conversion tool, 2to3 (http://docs.python.org/release/3.0/
> library/2to3.html#to3-reference), which automatically upgrades 2.x source
> code to valid 3.0 Python syntax.

Python is a more superficial language. Upgrading Python sources is bit like
replacing the old window frames in a house; upgrading C is more like
replacing the mortar between the bricks.

Also it would be necessary to partition C between old C, and new C
(equivalent of versions 2.x and 3.x), and to maintain that strict
delineation. With C sources appearing everywhere on the internet, it would
be a nightmare. Effectively you would be creating a new language. It
wouldn't be worth the trouble unless you tidied up a few other things too,
and then you really would have a new language.

> It would be a simple matter to write a converter that read a C source
> file and replaced all = assignment operators with :=

Actually it's not the simple, not at the character level anyway. Even using
a parser, there will be ambiguities.

> Incidentally, Python has many convenient features that could easily be
> added to C, e.g. multiple comparisons behave correctly (a < b > c etc);
> array and string slicing e.g. s[4:7] as a shortcut for strndup(s+4,3);
> else clauses on loops; and many more. Unfortunately the current fashion
> seems to be to try to preserve C in aspic.

As far as syntax is concerned, that's true. Even the spin-off languages
(even the latest Dart) have virtually the same 40-year-old syntax. And
strangely those languages haven't taken the opportunity to change "=" to
":=".

--
Bartc

[lawrenc...@siemens.com]

James Kuyper <james...@verizon.net> wrote:
>
> I generically dislike while(1) loops

In that case, use a for (;;) loop instead. :-)
--
Larry Jones

What's the matter? Don't you trust your own kid?! -- Calvin

[Keith Thompson]

Malcolm McLean <malcolm...@btinternet.com> writes:
> On Nov 9, 2:34 am, Keith Thompson <ks...@mib.org> wrote:
>>
>> So tell us, how would you address the problem of existing code that
>> uses "=" for assignment, and of new code using ":=" for assignment
>> that would no longer compile with older compilers?  Similarly,
>> how would you address the legions of C programmers who believe
>> (rightly or wrongly) that using "=" for assignment and "==" for
>> equality is ok, and doesn't need to be fixed?
>>
> You need to make the change compulsory, so the Luddites will have to
> use old compilers. Otherwise you get a worse mess than the one you
> were trying to solve. The new compiler gives an error, "old style
> assignment operator: please run makenewstyle". So you type
> makenewstyle *.c, and within seconds, all your code compiles.

And you check it all into your source control system, and re-test
everything, and re-release all of it. Updating the source files
is a tiny fraction of the overhead imposed by a change like this.

> There are some potential problems with diff and so on. If you've got a
> decent version control system then the new code is just flagged as a
> "new version", and it's no different to adding a comment, maybe a
> copyright notice to comply with new corporate policy. But there will
> be people for whom having two logically identical but textually
> different source files will be a nuisance. Then for a while there will
> be both old and new compilers in existence. You can't break old code
> without some problems.
>
> However old code with implict int will generate an unacceptable
> cascade of warnings on new compilers. implicit int has just about died
> out, together with old style function declarations. Changes are
> possible.

The use of implicit int was never mandatory. The 1989 ANSI standard
kept the feature. C99 dropped it, but most compilers still accept
it with a warning. And if you change all your old code to declare
return types explicitly, it still compiles with old compilers.

As for old-style function declarations, they're still in the
language, even though they're clearly inferior to prototypes.
Even in the latest C201X draft they're still merely "an obsolescent
feature"; compilers are still required to support them.

In both cases, the changes to source code could be made
incrementally.

Changing "=" to ":=" as you propose is an all-or-nothing change.
If the C201X standard made such a change (it won't), there would
be a transition period of, probably, a couple of decades in which
you could either ignore the new standard altogether (the most
likely outcome for most programmers), *or* you could maintain two
versions of every single C source file. That maintenance could be
largely automated, but there would be as many inconsistent automated
solutions as there are development environments.

Oh, and try getting agreement from the C++ standard committee while
you're at it. And Objective-C (I don't know whether there's a
committee for that, but Objective-C is closely upward-compatible
with C).

If your goal is to kill an future development of the C standard,
making a wide-reaching change like this for fairly trivial benefit
is a good way to do it.

Or here's another idea. Leave "=" the way it is, and let compilers
issue an optional warning when "=" is used in a context where "=="
is probably what was meant.

[Keith Thompson]

"BartC" <b...@freeuk.com> writes:
> "Edward Rutherford" <edward.p.r...@REMOVETHIS.gmail.com> wrote
> in message news:j9eceq$jb3$1...@speranza.aioe.org...

[...]

> Also it would be necessary to partition C between old C, and new C
> (equivalent of versions 2.x and 3.x), and to maintain that strict
> delineation. With C sources appearing everywhere on the internet, it
> would be a nightmare. Effectively you would be creating a new
> language. It wouldn't be worth the trouble unless you tidied up a few
> other things too, and then you really would have a new language.

There's no shortage of new languages. I have no objection at all to
ceating a new C-like language that uses ":=" for assignment and "==" for
equality. It just can't practically be a replacement for C, and it
shouldn't be called "C".

>> It would be a simple matter to write a converter that read a C source
>> file and replaced all = assignment operators with :=
>
> Actually it's not the simple, not at the character level anyway. Even
> using a parser, there will be ambiguities.

With a parser, or even just a lexer, there shouldn't be any ambiguities.
Just tokenize the source and replace every "=" token with a ":=" token.
This assumes, of course, that "=" is changed to ":=" both for
assignments and for initializers. Compound assignments presumably
wouldn't be affected; "+=" would still be "+=", not "+:=".

There might be some odd corner cases involving the preprocessor.

[Ian Collins]

On 11/10/11 10:25 AM, Keith Thompson wrote:
> Malcolm McLean<malcolm...@btinternet.com> writes:
>> On Nov 9, 2:34 am, Keith Thompson<ks...@mib.org> wrote:
>>>
>>> So tell us, how would you address the problem of existing code that
>>> uses "=" for assignment, and of new code using ":=" for assignment
>>> that would no longer compile with older compilers? Similarly,
>>> how would you address the legions of C programmers who believe
>>> (rightly or wrongly) that using "=" for assignment and "==" for
>>> equality is ok, and doesn't need to be fixed?
>>>
>> You need to make the change compulsory, so the Luddites will have to
>> use old compilers. Otherwise you get a worse mess than the one you
>> were trying to solve. The new compiler gives an error, "old style
>> assignment operator: please run makenewstyle". So you type
>> makenewstyle *.c, and within seconds, all your code compiles.
>
> And you check it all into your source control system, and re-test
> everything, and re-release all of it. Updating the source files
> is a tiny fraction of the overhead imposed by a change like this.

To be fair, you would have to do this for any compiler upgrade. But I
do agree this is a silly idea!

--
Ian Collins

[Keith Thompson]

Ok, that's not a bad answer. I still don't think that it would be
at all practical to change C's assignment operator from "=" to ":=".
The overhead would be substantial, probably enough to cause many
implementers and programmers to ignore any new standard that made
such a change. (Getting C99 adopted has been difficult enough.)
C programming culture is not Python programming culture. And I'll
note that Python 2 is not dying with the introduction of Python 3.

> Incidentally, Python has many convenient features that could easily be
> added to C, e.g. multiple comparisons behave correctly (a < b > c etc);
> array and string slicing e.g. s[4:7] as a shortcut for strndup(s+4,3);
> else clauses on loops; and many more. Unfortunately the current fashion
> seems to be to try to preserve C in aspic.

"a < b > c" already has a meaning in C; it's equivalent to
"(a < b) > c", where "(a < b)" yields either 0 or 1. I suspect
that such constructs are used in error more often than they're used
correctly, but the committee is rightly hesitant to make changes
that can break existing code. And it's not *that* hard to write
"a < b && b > c".

I can't think of a way to define "s[4:7]" consistently in C without
radically changing the way C deals with strings and arrays. Suppose
s is a string with the value "Hello, world"; it's represented as an
array containing those 12 characters followed by a terminating '\0'.
s[4:7] should be the string "o, w", but that requires building an
array somewhere in memory with a '\0' immediately following the
'w'; you can't just treat a subset of "Hello, world" as "o, w".
And that means you have to deal with allocating, initializing,
and deallocating it.

I'm not saying that C's string and array handling are an ideal
solution, but there are uncounted millions of lines of code that
depend on it.

As for "preserv[ing] C in aspic", I refer you to
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf, the latest
(?) draft of the upcoming C201X standard. It adds threading,
alignment support, Unicode support, type-generic expressions,
static assertions, optional support for bounds-checking interfaces,
and a number of other things.

[Robert Wessel]

On Wed, 09 Nov 2011 13:31:07 -0800, Keith Thompson <ks...@mib.org>
wrote:

>"BartC" <b...@freeuk.com> writes:
>> "Edward Rutherford" <edward.p.r...@REMOVETHIS.gmail.com> wrote
>> in message news:j9eceq$jb3$1...@speranza.aioe.org...
>[...]
>> Also it would be necessary to partition C between old C, and new C
>> (equivalent of versions 2.x and 3.x), and to maintain that strict
>> delineation. With C sources appearing everywhere on the internet, it
>> would be a nightmare. Effectively you would be creating a new
>> language. It wouldn't be worth the trouble unless you tidied up a few
>> other things too, and then you really would have a new language.
>
>There's no shortage of new languages. I have no objection at all to
>ceating a new C-like language that uses ":=" for assignment and "==" for
>equality. It just can't practically be a replacement for C, and it
>shouldn't be called "C".
>
>>> It would be a simple matter to write a converter that read a C source
>>> file and replaced all = assignment operators with :=
>>
>> Actually it's not the simple, not at the character level anyway. Even
>> using a parser, there will be ambiguities.
>
>With a parser, or even just a lexer, there shouldn't be any ambiguities.
>Just tokenize the source and replace every "=" token with a ":=" token.
>This assumes, of course, that "=" is changed to ":=" both for
>assignments and for initializers. Compound assignments presumably
>wouldn't be affected; "+=" would still be "+=", not "+:=".
>
>There might be some odd corner cases involving the preprocessor.

Indeed:

#define qq(x) "a" #x "b"
char s[]=qq(=);

Perhaps a somewhat contrived example, but still representative of a
class of potential problems for an automated conversion.

[BartC]

"Keith Thompson" <ks...@mib.org> wrote in message
news:ln4nyda...@nuthaus.mib.org...

> "BartC" <b...@freeuk.com> writes:
>> "Edward Rutherford" <edward.p.r...@REMOVETHIS.gmail.com> wrote

>>> It would be a simple matter to write a converter that read a C source
>>> file and replaced all = assignment operators with :=
>>

>> Actually it's not [that] simple, not at the character level anyway. Even

>> using a parser, there will be ambiguities.
>
> With a parser, or even just a lexer, there shouldn't be any ambiguities.
> Just tokenize the source and replace every "=" token with a ":=" token.
> This assumes, of course, that "=" is changed to ":=" both for
> assignments and for initializers.

OK, that means a lexer will do instead of a parser. Although it will look
odd for static initialisers because ":=" looks more of a dynamic, runtime
assignment than a passive "=". (But more of an oddity would be having a
language that uses ":=" for assignment, but doesn't let you use "=" for
equality; you have to still use "==".)

> Compound assignments presumably
> wouldn't be affected; "+=" would still be "+=", not "+:=".

> There might be some odd corner cases involving the preprocessor.

What about commented-out code, or (rarer) code fragments inside literals?

--
Bartc

[Keith Thompson]

"BartC" <b...@freeuk.com> writes:
[...]

>> There might be some odd corner cases involving the preprocessor.
>
> What about commented-out code, or (rarer) code fragments inside literals?

It would have to be left alone. An automated tool should not make
assumptions about the meaning of text in comments or string literals.

Any tools that generate C code (and there are a *lot* of them)
would have to be modified as well, probably with an option to
generate old-style or new-style assignment operators.

[Kaz Kylheku]

On 2011-11-09, Malcolm McLean <malcolm...@btinternet.com> wrote:
> On Nov 9, 2:34 am, Keith Thompson <ks...@mib.org> wrote:
>>
>> So tell us, how would you address the problem of existing code that
>> uses "=" for assignment, and of new code using ":=" for assignment
>> that would no longer compile with older compilers?  Similarly,
>> how would you address the legions of C programmers who believe
>> (rightly or wrongly) that using "=" for assignment and "==" for
>> equality is ok, and doesn't need to be fixed?
>>
> You need to make the change compulsory, so the Luddites will have to

If I could make such things compulsory, I wouldn't bother with compilers. I
would make it compulsory for, say, everyone in North America to give me a
dollar.

To hell with making some programmers use a different compiler.

[Joe Pfeiffer]

r...@zedat.fu-berlin.de (Stefan Ram) writes:

> James Kuyper <james...@verizon.net> writes:
>>On 11/08/2011 05:10 PM, Keith Thompson wrote:
>>> while (1) {
>>> int c = getchar();

>>> if (c == EOF) break;
>>> process_char(c);
>>> }

>>I generically dislike while(1) loops
>

> What I do sometimes in difficult cases is the looping loop:
>
> for( int looping = 1; looping; )
> { int const c = getchar();
> if( c == EOF || feof( stdin )|| ferror( stdin ))looping = 0;
> else process( c ); }

Of course, your looping loop doesn't translate a while(1). The while()
equivalent (going back to the OP's logic, and switching the if to what I
prefer) would be

looping = 1;
while (looping) {
int c = getchar();
if (c != EOF)
process(c);
else
looping = 0;
}

[Kaz Kylheku]

Many times in the past, I have found useful the following approach:

Code a loop with no guard condition, but with a break at the end.

Then use explicit continue statements to continue iterating:

for (;;) {
int c = getchar();

/* look at C and handle cases which should continue */
switch (c) {
case '{':
...
continue;
case '!':
...
continue;
EOF:
break;
}

break;
}

This also solves the problem that "break" inside the switch does not
break out of the loop. We break out of the loop by falling to the end;
to continue the loop we use continue, which is not intercepted
by switch.

[Malcolm McLean]

On Nov 9, 11:25 pm, Keith Thompson <ks...@mib.org> wrote:
>
> Or here's another idea.  Leave "=" the way it is, and let compilers
> issue an optional warning when "=" is used in a context where "=="
> is probably what was meant.
>

I've used compilers which did that

while(ch = fgetc(fp))

would trigger a warning

while( (ch = fgetc(fp)) != 0)

would not.

[Nick Keighley]

On Nov 9, 9:25 pm, Keith Thompson <ks...@mib.org> wrote:

<snip>

> Changing "=" to ":=" as you propose is an all-or-nothing change.
> If the C201X standard made such a change (it won't), there would
> be a transition period of, probably, a couple of decades in which
> you could either ignore the new standard altogether (the most
> likely outcome for most programmers), *or* you could maintain two
> versions of every single C source file.  That maintenance could be
> largely automated, but there would be as many inconsistent automated
> solutions as there are development environments.
>
> Oh, and try getting agreement from the C++ standard committee while
> you're at it.  And Objective-C (I don't know whether there's a
> committee for that, but Objective-C is closely upward-compatible
> with C).

what about C#, Java, Python
or is that just too much?

<snip>

[Phil Carmody]

Kaz Kylheku <k...@kylheku.com> writes:
> On 2011-11-08, Edward Rutherford <edward.p.r...@REMOVETHIS.gmail.com> wrote:

> > Keith Thompson wrote:
> >
> >> Using "=" for assignment was not, in my opinion, a good idea. Any
> >> attempt to change it now would be far worse.
> >
> > With this attitude, the language will never improve!
>

> Inextensible languages like C do improve or at least evolve by creating
> spin-offs which are new languages. Some are backward-compatible (Objective C).
> Some have a lot of backward compatibility (C++). Others are incompatible
> (Java).
>
> Speaking of which, even though Java is not meant to be compatible with C, its
> assignment operator is = and comparison is ==.
>
> Oops!

As is JavaScript's, and perl's, and LUA's, and python's ...

Was the decision really such a bad mistake if it's been willingly
repeated so often?

I'll pin my colours to the mast - I do not consider the choice of those
tokens to be a mistake.

Phil
--
Unix is simple. It just takes a genius to understand its simplicity
-- Dennis Ritchie (1941-2011), Unix Co-Creator

[Keith Thompson]

Nick Keighley <nick_keigh...@hotmail.com> writes:
> On Nov 9, 9:25 pm, Keith Thompson <ks...@mib.org> wrote:
> <snip>

[...]

>> Oh, and try getting agreement from the C++ standard committee while
>> you're at it.  And Objective-C (I don't know whether there's a
>> committee for that, but Objective-C is closely upward-compatible
>> with C).
>
> what about C#, Java, Python
> or is that just too much?

If C made such a change, there would be no particular motivation
for C#, Java, or Python to follow suit. C++ and Objective-C have
C compatibility as a significant selling point.

[Ben Bacarisse]

Phil Carmody <thefatphi...@yahoo.co.uk> writes:
<snip>

> I'll pin my colours to the mast - I do not consider the choice of those
> tokens to be a mistake.

No, me neither, though I have a slight preference for an asymmetric
symbol for assignment since the operation is asymmetric.

More to the point, I don't recall any "hard" bug being caused by a =/==
confusion. Sure, it happens, but the bug shows up immediately the code
is tested. In contrast, A </<= error (which can be either a typo or a
misunderstanding) can often be quite hard to track down. Does anyone
recall a =/== bug that was anything but trivial?

--
Ben.

[BartC]

"Phil Carmody" <thefatphi...@yahoo.co.uk> wrote in message
news:87ty6cd...@bazspaz.fatphil.org...

> Kaz Kylheku <k...@kylheku.com> writes:

>> Speaking of which, even though Java is not meant to be compatible with C,
>> its
>> assignment operator is = and comparison is ==.
>>
>> Oops!
>
> As is JavaScript's, and perl's, and LUA's, and python's ...
>
> Was the decision really such a bad mistake if it's been willingly
> repeated so often?

Those languages were likely implemented in C. In which case, they would be
quite receptive to the idea of using "=" and "==".

And if they had considered using ":=" and "=" instead, they would quickly
have found that mixing up ":="/"=" and "="/"==" (between writing the C code
and testing fragments of the new language) caused too many problems!

> I'll pin my colours to the mast - I do not consider the choice of those
> tokens to be a mistake.

In the original C, or the derived languages? Once the decision to use "="
for assignment in C was made, using "==" for equality was reasonable. Using
.EQ. would be too naff, and using context was not possible as assignments
also occur in expressions.

(I think PL/I allowed "=" for both assignment/equality, maybe it did use
context, but that was quite hairy to implement anyway.)

--
Bartc

[88888 Dihedral]

I think in C the assignment = is OK. But if C is to be used to model HW circuits then the blocking and non-blocking assignment is different. There is ways around!
For example, use an object way that the next property for HW objects to change values. C++ people usually don't like to talk about HW related properties such as pointers in C and pointer operations and stacks in compilers. Thus C is better to extend its usage in HW descriptions in the future. ANSI ASCII was an encode to express color letters in BBS in 199X. And that time those BBS programs are most written in C. Now html/xml/CSS take over the jobs!

[Kenny McCormack]

In article <ln39dw9...@nuthaus.mib.org>,

Keith Thompson <ks...@mib.org> wrote:
>Nick Keighley <nick_keigh...@hotmail.com> writes:
>> On Nov 9, 9:25 pm, Keith Thompson <ks...@mib.org> wrote:
>> <snip>
>[...]
>>> Oh, and try getting agreement from the C++ standard committee while
>>> you're at it.  And Objective-C (I don't know whether there's a
>>> committee for that, but Objective-C is closely upward-compatible
>>> with C).
>>
>> what about C#, Java, Python
>> or is that just too much?
>
>If C made such a change, there would be no particular motivation
>for C#, Java, or Python to follow suit. C++ and Objective-C have
>C compatibility as a significant selling point.

Add AWK & Perl to the list. The point is that one of the selling points of
those languages is that the syntax (including the structure and the
operators) is C-like. If you change C, then they'd either have to change as
well, or lose that selling point.

And anyway, isn't it a standard dogma of this group that C and C++ are
completely different languages with almost nothing in common? That's what I
hear all the time...

--
(This discussion group is about C, ...)

Wrong. It is only OCCASIONALLY a discussion group
about C; mostly, like most "discussion" groups, it is
off-topic Rorsharch [sic] revelations of the childhood
traumas of the participants...

[Lauri Alanko]

In article <83205f44-2ef4-4f1c...@y7g2000vbe.googlegroups.com>,

Nick Keighley <nick_keigh...@hotmail.com> wrote:
> On Nov 9, 9:25 pm, Keith Thompson <ks...@mib.org> wrote:
> > Changing "=" to ":=" as you propose is an all-or-nothing change.

> > Oh, and try getting agreement from the C++ standard committee while
> > you're at it.

> what about C#, Java, Python
> or is that just too much?

Python does not have assignment expressions, so the issue is moot.


Lauri

[Phil Carmody]

"BartC" <b...@freeuk.com> writes:
> "Phil Carmody" <thefatphi...@yahoo.co.uk> wrote in message
> news:87ty6cd...@bazspaz.fatphil.org...
> > Kaz Kylheku <k...@kylheku.com> writes:
>
> >> Speaking of which, even though Java is not meant to be compatible
> >> with C, its
> >> assignment operator is = and comparison is ==.
> >>
> >> Oops!
> >
> > As is JavaScript's, and perl's, and LUA's, and python's ...
> >
> > Was the decision really such a bad mistake if it's been willingly
> > repeated so often?
>
> Those languages were likely implemented in C. In which case, they
> would be quite receptive to the idea of using "=" and "==".

Probably so. They didn't consider themselves hostages to some
egregious 'mistake', that they had to escape from forthwith,
that's for sure. It still makes them valid data points against
the hypothesis that the choice was a mistake.

> And if they had considered using ":=" and "=" instead, they would
> quickly have found that mixing up ":="/"=" and "="/"==" (between
> writing the C code and testing fragments of the new language) caused
> too many problems!

In some of those languages, the visual similarity is minuscule, so I
don't think that would be an issue - their test inputs are simply not
comparable to the language the compiler/interpreter's written in.

> > I'll pin my colours to the mast - I do not consider the choice of those
> > tokens to be a mistake.
>
> In the original C, or the derived languages?

In C. And I support its borrowing in all languages that want to inherit
some C-like syntax, as long as holistically it's coherent enough.

> Once the decision to use
> "=" for assignment in C was made, using "==" for equality was
> reasonable.

No more or less reasonable than something like =?, though. OK, the
set of arbitrary and vaguely sensible things it could have been isn't
huge, but it's certainly not a singleton.

> Using .EQ. would be too naff, and using context was not
> possible as assignments also occur in expressions.
>
> (I think PL/I allowed "=" for both assignment/equality, maybe it did
> use context, but that was quite hairy to implement anyway.)

Whilst I don't have a background in those languages, I do not feel
that I am lacking in any way! (But I'm happy to have studied scheme,
for example.)

[Jorgen Grahn]

On Thu, 2011-11-10, Kenny McCormack wrote:
...

> And anyway, isn't it a standard dogma of this group that C and C++ are
> completely different languages with almost nothing in common? That's what I
> hear all the time...

They are completely different languages, with a lot in common.

/Jorgen

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .

[Kaz Kylheku]

On 2011-11-12, Jorgen Grahn <grahn...@snipabacken.se> wrote:
> On Thu, 2011-11-10, Kenny McCormack wrote:
> ...
>> And anyway, isn't it a standard dogma of this group that C and C++ are
>> completely different languages with almost nothing in common? That's what I
>> hear all the time...
>
> They are completely different languages, with a lot in common.

Your English dictionary must have something bizarre under the "completely"
entry.

[Charles Richmond]

"Kaz Kylheku" <k...@kylheku.com> wrote in message
news:201111121...@kylheku.com...

It is analogous to what George Bernard Shaw said:

"England and America are two countries separated by a common language."

--
+<><><><><><><><><><><><><><><><><><><>+
| Charles Richmond nume...@aquaporin4.com |
+<><><><><><><><><><><><><><><><><><><>+

[Kaz Kylheku]

On 2011-11-13, Charles Richmond <net...@aquaporin4.com> wrote:
> "Kaz Kylheku" <k...@kylheku.com> wrote in message
> news:201111121...@kylheku.com...
>> On 2011-11-12, Jorgen Grahn <grahn...@snipabacken.se> wrote:
>>> On Thu, 2011-11-10, Kenny McCormack wrote:
>>> ...
>>>> And anyway, isn't it a standard dogma of this group that C and C++ are
>>>> completely different languages with almost nothing in common? That's
>>>> what I
>>>> hear all the time...
>>>
>>> They are completely different languages, with a lot in common.
>>
>> Your English dictionary must have something bizarre under the "completely"
>> entry.
>
> It is analogous to what George Bernard Shaw said:
>
> "England and America are two countries separated by a common language."

I'm working on a program that can be built either with a C or C++ compiler.
Most of the time I forget about this, losing my awareness of "this has to be
valid C++ too", and I neglect to build it as C++ for weeks or months.

Yet, the C++ port very rarely breaks and is easy to fix.

I just tried a C++ build: zero warnings! According to the ChangeLog, the last
time I did C++-related maintenance was on Oct 2, which was 131 commits ago. So
did 131 commits to a C program without caring that it's also C++, yet it still
compiles cleanly as C++.

C++ is a very close dialect of C, and can easily be treated as another porting
target for a C program.

[Robert Wessel]

I think that (fairly rare) case has been acknowledged a number of
times. The point is that, outside a few specialized requirements, and
while you can produce programs that compile under either, C and C++
are sufficiently different languages, such that essentially no
meaningful well written C programs could be considered a well written
C++ program. IOW, good C code is bad C++ code, even if it does
compile and run under the latter.

[Kenny McCormack]

In article <201111130...@kylheku.com>,
Kaz Kylheku <k...@kylheku.com> wrote:
...

>C++ is a very close dialect of C, and can easily be treated as another porting
>target for a C program.

uh oh. Kiki isn't going to like this...

--
Just for a change of pace, this sig is *not* an obscure reference to
comp.lang.c...

[Keith Thompson]

Kaz Kylheku <k...@kylheku.com> writes:
[...]

> I'm working on a program that can be built either with a C or C++ compiler.
> Most of the time I forget about this, losing my awareness of "this has to be
> valid C++ too", and I neglect to build it as C++ for weeks or months.

[...]

Out of curiosity, why are you doing this? What advantage do you gain
by writing code that can compile in either language? Conversely,
what would you lose by not worrying at all about C++ compatibility
(go ahead and call that variable "class" if you like)?

My impression is that the actual need for this is much rarer than
many people seem to think it is. (I do not include you in those
"many people").

[Kaz Kylheku]

On 2011-11-13, Keith Thompson <ks...@mib.org> wrote:
> Kaz Kylheku <k...@kylheku.com> writes:
> [...]
>> I'm working on a program that can be built either with a C or C++ compiler.
>> Most of the time I forget about this, losing my awareness of "this has to be
>> valid C++ too", and I neglect to build it as C++ for weeks or months.
> [...]
>
> Out of curiosity, why are you doing this? What advantage do you gain
> by writing code that can compile in either language?

I can write in a "better C", which is safer, but still compiles with C
compilers.

> Conversely,
> what would you lose by not worrying at all about C++ compatibility
> (go ahead and call that variable "class" if you like)?

One example would be that I can't build the code any more with C++ to check
that all external names are meeting type-safe linkage and the one-definition
rule.

In C, I can have "extern int x;" in in one module, and "struct foo x = { 0 };"
in another. It will link.

If you change a C program such that a function has different parameters, but
due to some broken dependencies in your build system, some dependent modules
are not recompiled, you will get a broken link. Of course, it goes away
if you do a complete rebuild, but you could waste time chasing a bug
which isn't there.

This is fixed in C++: it will catch your broken build system. Type
safe linkage won't let an int (int, char *) call go to an
int (int, char *, char *) function.

(Ironically, I had such a problem recently and didn't catch it because
I had the project configured for the C compiler!)

The real question is, why not break away from C compatibility
and just use arbitrary C++?

That's the real reason for doing this: portability. I believe that C compilers
are still more widely available. Also more widely installed. If we look at just
GNU/Linux systems, g++ will never be present without gcc. But gcc will be
present without g++.

By the way, coding this way may come upon you as a feature request
from users! Years ago I developed that Kazlib library and I made sure
the headers were squeaky clean for C++ use.

But what did some people do? They took the .c files into their C++ projects and
compiled them as C++. So I got e-mails like, "hey your code breaks C++,
can we patch it".

This is probably one niche area where you need to write
in this common dialect: whitebox-reuse libraries that can be dropped
into C or C++ projects.

That's probably when I became more receptive to the idea that hey;
you can write C and C++ at the same time.

> My impression is that the actual need for this is much rarer than
> many people seem to think it is. (I do not include you in those
> "many people").

It's usually not a need, but an easily obtained "nice to have".

You won't see this done very often not because it is awkward or cumbersome
(which it isn't) but because (no surprise) most of the development world
doesn't really care about portability at all, let alone portability of C++ code
to C compilers.

[Nick Keighley]

On Nov 13, 4:57 pm, Kaz Kylheku <k...@kylheku.com> wrote:

> On 2011-11-13, Charles Richmond <netn...@aquaporin4.com> wrote:
>
>
>
>
>
> > "Kaz Kylheku" <k...@kylheku.com> wrote in message
> >news:201111121...@kylheku.com...

> >> On 2011-11-12, Jorgen Grahn <grahn+n...@snipabacken.se> wrote:
> >>> On Thu, 2011-11-10, Kenny McCormack wrote:
> >>> ...
> >>>> And anyway, isn't it a standard dogma of this group that C and C++ are
> >>>> completely different languages with almost nothing in common?  That's
> >>>> what I
> >>>> hear all the time...
>
> >>> They are completely different languages, with a lot in common.
>
> >> Your English dictionary must have something bizarre under the "completely"
> >> entry.
>
> > It is analogous to what George Bernard Shaw said:
>
> > "England and America are two countries separated by a common language."
>
> I'm working on a program that can be built either with a C or C++ compiler.
> Most of the time I forget about this, losing my awareness of "this has to be
> valid C++ too", and I neglect to build it as C++ for weeks or months.
>
> Yet, the C++ port very rarely breaks and is easy to fix.
>
> I just tried a C++ build: zero warnings! According to the ChangeLog, the last
> time I did C++-related maintenance was on Oct 2, which was 131 commits ago. So
> did 131 commits to a C program without caring that it's also C++, yet it still
> compiles cleanly as C++.
>
> C++ is a very close dialect of C, and can easily be treated as another porting
> target for a C program.

"the C subset of C++ is a very close dialect of C..."

[Ike Naar]

On 2011-11-14, Kaz Kylheku <k...@kylheku.com> wrote:
> One example would be that I can't build the code any more with C++ to check
> that all external names are meeting type-safe linkage and the one-definition
> rule.
>
> In C, I can have "extern int x;" in in one module, and "struct foo x = { 0 };"
> in another. It will link.
>
> If you change a C program such that a function has different parameters, but
> due to some broken dependencies in your build system, some dependent modules
> are not recompiled, you will get a broken link. Of course, it goes away
> if you do a complete rebuild, but you could waste time chasing a bug
> which isn't there.
>
> This is fixed in C++: it will catch your broken build system. Type
> safe linkage won't let an int (int, char *) call go to an
> int (int, char *, char *) function.

Using a C++ compiler (GCC 4.1.2), the following:

/* a.cxx */
extern int x;
int main() { return x; }

/* b.cxx */
struct foo { double d; } x;

compiles/links (c++ -ansi -pedantic -Wall a.cxx b.cxx)
and runs without any complaints.

[Kaz Kylheku]

Ah yes, g++ is broken in this regard.

But the ODR still kicks in.

In a program where there are duplicate uses of an external name like this,
there are likely to be multiple definitions. E.g. two modules in some large
program both happen to use a global variable x.

Perhaps two developers did parallel commits in different modules, both
introducing it, and you, the build master, pull both changes from the repo.

$ cat a.cc
int x;
$ cat b.cc
struct foo { int a; } x;

int main()
{
}
$ g++ a.cc b.cc
/tmp/ccJExOCi.o:(.bss+0x0): multiple definition of `x'
/tmp/ccbKi3U5.o:(.bss+0x0): first defined here
collect2: ld returned 1 exit status

So at least there is that. Of course if one module, by mistake, neglects to
define its global, then the ball gets by the goalkeeper, so to peak.

If these changes are made separately (e.g. two developers in separate
sandboxes) the one with the missing definition will hopefully catch it, since
it doesn't link.

But change to C:

$ cp a.cc a.c
$ cp b.cc b.c
$ gcc a.c b.c

Multiple defs; not a peep.

If "perfect" is not available, I will still take "better".

[James Kuyper]

There's only one definition of 'foo' in this program; the one in b.cxx.
a.cxx only contains a declaration of the object. Even if this were a
violation of the ODR, section 3.2p3 of the C++ standard says, very
explicitly, "no diagnostic required", which would make it no different
from C in this regard.

The relevant rule is actually in section 3.5p10 of the C++ standard:
"... the types specified by all declarations referring to a given object
or function shall be identical, ...", but in that case, too, it says
very explicitly that "A violation of this rule on type identity does not
require a diagnostic." So again, it's no different from C.

If some C++ compilers provide diagnostics that are not required, that's
a feature of those particular compilers, not a feature of the C++
language itself, and a feature that could have been put into C compilers.

(all citations are from n3035.pdf, which is the closest thing I have to
the actual C++ standard that is readily available. However, I don't
believe that either of these citations are significantly different from
previous versions of the standard, nor from more recent drafts of the
next standard).

[Ben Bacarisse]

Kaz Kylheku <k...@kylheku.com> writes:

> On 2011-11-14, Ike Naar <i...@sverige.freeshell.org> wrote:

<snip>

>> Using a C++ compiler (GCC 4.1.2), the following:
>>
>> /* a.cxx */
>> extern int x;
>> int main() { return x; }
>>
>> /* b.cxx */
>> struct foo { double d; } x;
>>
>> compiles/links (c++ -ansi -pedantic -Wall a.cxx b.cxx)
>> and runs without any complaints.
>
> Ah yes, g++ is broken in this regard.
>
> But the ODR still kicks in.
>
> In a program where there are duplicate uses of an external name like this,
> there are likely to be multiple definitions. E.g. two modules in some large
> program both happen to use a global variable x.

<snip>

> But change to C:
>
> $ cp a.cc a.c
> $ cp b.cc b.c
> $ gcc a.c b.c
>
> Multiple defs; not a peep.
>
> If "perfect" is not available, I will still take "better".

-fno-common is handy for this.

--
Ben.

[David Thompson]

On Thu, 10 Nov 2011 12:23:06 -0000, "BartC" <b...@freeuk.com> wrote:

> "Phil Carmody" <thefatphi...@yahoo.co.uk> wrote in message
> news:87ty6cd...@bazspaz.fatphil.org...
> > Kaz Kylheku <k...@kylheku.com> writes:
>
> >> Speaking of which, even though Java is not meant to be compatible with C,
> >> its assignment operator is = and comparison is ==.
> >>
> >> Oops!
> >
> > As is JavaScript's, and perl's, and LUA's, and python's ...
> >
> > Was the decision really such a bad mistake if it's been willingly
> > repeated so often?
>
> Those languages were likely implemented in C. In which case, they would be
> quite receptive to the idea of using "=" and "==".
>

The implementation language as such doesn't matter; SQL and HTML,
among many other things, are often implemented in C (or C++, which
keeps all the same basic syntax) but look nothing alike.

> And if they had considered using ":=" and "=" instead, they would quickly
> have found that mixing up ":="/"=" and "="/"==" (between writing the C code
> and testing fragments of the new language) caused too many problems!
>

That's a benefit, but I think a small one. More important, if the
designers/ implementors have experience of using C (or C++) without
trouble, and especially if they expect or find their users do so, then
following the path already blazed makes life easier.

>
> > I'll pin my colours to the mast - I do not consider the choice of those
> > tokens to be a mistake.
>
> In the original C, or the derived languages? Once the decision to use "="
> for assignment in C was made, using "==" for equality was reasonable. Using
> .EQ. would be too naff, and using context was not possible as assignments
> also occur in expressions.
>
> (I think PL/I allowed "=" for both assignment/equality, maybe it did use
> context, but that was quite hairy to implement anyway.)

PL/I does indeed, but it has assignment as a statement only at
toplevel not a nestable expression. The harder problem in parsing
PL/I, for both compiler and human, is unreserved keywords.

COBOL similarly has no trouble distinguishing
COMPUTE x = y .
IF a = b THEN blah .

and SQL
SELECT x FROM t WHERE y = 3;
UPDATE t SET x = 17;