Velocity Reviews > John McCarthy died today.

# John McCarthy died today.

Stefan Ram
Guest
Posts: n/a

 11-10-2011
James Kuyper <(E-Mail Removed)> 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 ); }

Joe Pfeiffer
Guest
Posts: n/a

 11-10-2011
http://www.velocityreviews.com/forums/(E-Mail Removed)-berlin.de (Stefan Ram) writes:

> James Kuyper <(E-Mail Removed)> 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
Guest
Posts: n/a

 11-10-2011
On 2011-11-10, Joe Pfeiffer <(E-Mail Removed)> wrote:
> (E-Mail Removed)-berlin.de (Stefan Ram) writes:
>
>> James Kuyper <(E-Mail Removed)> 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;
> }

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
Guest
Posts: n/a

 11-10-2011
On Nov 9, 11:25*pm, Keith Thompson <(E-Mail Removed)> 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
Guest
Posts: n/a

 11-10-2011
On Nov 9, 9:25*pm, Keith Thompson <(E-Mail Removed)> 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).

or is that just too much?

<snip>

Phil Carmody
Guest
Posts: n/a

 11-10-2011
Kaz Kylheku <(E-Mail Removed)> writes:
> On 2011-11-08, Edward Rutherford <(E-Mail Removed)> 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
Guest
Posts: n/a

 11-10-2011
Nick Keighley <(E-Mail Removed)> writes:
> On Nov 9, 9:25Â*pm, Keith Thompson <(E-Mail Removed)> 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.

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

Ben Bacarisse
Guest
Posts: n/a

 11-10-2011
Phil Carmody <(E-Mail Removed)> 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
Guest
Posts: n/a

 11-10-2011
"Phil Carmody" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> Kaz Kylheku <(E-Mail Removed)> 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
Guest
Posts: n/a

 11-10-2011
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!