Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > John McCarthy died today.

Reply
Thread Tools

John McCarthy died today.

 
 
lawrence.jones@siemens.com
Guest
Posts: n/a
 
      11-08-2011
James Kuyper <(E-Mail Removed)> 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
 
Reply With Quote
 
 
 
 
Phil Carmody
Guest
Posts: n/a
 
      11-08-2011
Kaz Kylheku <(E-Mail Removed)> writes:
> On 2011-11-07, BartC <(E-Mail Removed)> wrote:
> > "Kaz Kylheku" <(E-Mail Removed)> wrote in message
> > news:(E-Mail Removed)...
> >
> >> 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?

Phil
--
Unix is simple. It just takes a genius to understand its simplicity
-- Dennis Ritchie (1941-2011), Unix Co-Creator
 
Reply With Quote
 
 
 
 
Kaz Kylheku
Guest
Posts: n/a
 
      11-08-2011
On 2011-11-08, James Kuyper <(E-Mail Removed)> 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!
 
Reply With Quote
 
James Kuyper
Guest
Posts: n/a
 
      11-08-2011
On 11/08/2011 11:48 AM, Kaz Kylheku wrote:
> On 2011-11-08, James Kuyper <(E-Mail Removed)> 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).

....
> 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.
 
Reply With Quote
 
Keith Thompson
Guest
Posts: n/a
 
      11-08-2011
James Kuyper <(E-Mail Removed)> 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);
}

--
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"
 
Reply With Quote
 
James Kuyper
Guest
Posts: n/a
 
      11-08-2011
On 11/08/2011 05:10 PM, Keith Thompson wrote:
> James Kuyper <(E-Mail Removed)> 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.
 
Reply With Quote
 
Keith Thompson
Guest
Posts: n/a
 
      11-08-2011
Malcolm McLean <(E-Mail Removed)> writes:
> On Nov 8, 12:06*am, Keith Thompson <(E-Mail Removed)> 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.

--
Keith Thompson (The_Other_Keith) (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"
 
Reply With Quote
 
Edward Rutherford
Guest
Posts: n/a
 
      11-08-2011
Keith Thompson wrote:

> Malcolm McLean <(E-Mail Removed)> writes:
>> On Nov 8, 12:06*am, Keith Thompson <(E-Mail Removed)> 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.


With this attitude, the language will never improve!
 
Reply With Quote
 
James Kuyper
Guest
Posts: n/a
 
      11-08-2011
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.
 
Reply With Quote
 
Kaz Kylheku
Guest
Posts: n/a
 
      11-08-2011
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!
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
DVD Verdict reviews: JOHN WAYNE-JOHN FORD FILM COLLECTION and more! DVD Verdict DVD Video 0 06-06-2006 08:23 AM
Printer & File Sharing Died =?Utf-8?B?Sm9obiBSYXR6ZW5iZXJnZXI=?= Wireless Networking 10 06-18-2005 07:50 PM
format first name from -john- to -John- ? RN ASP .Net 3 02-27-2005 05:34 AM
REVIEW: "The Hanged Man's Song", John Sandford (John Camp) Rob Slade, doting grandpa of Ryan and Trevor Computer Security 0 01-26-2004 04:28 PM
REVIEW: "The Devil's Code", John Sandford (John Camp) Rob Slade, doting grandpa of Ryan and Trevor Computer Security 0 07-03-2003 06:43 PM



Advertisments