Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #12065 > unrolled thread

John McCarthy died today.

Back to article view | Back to comp.lang.c

Contents

  John McCarthy died today. Kaz Kylheku <kaz@kylheku.com> - 2011-10-25 00:44 +0000
    Re: John McCarthy died today. Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-10-25 01:27 -0700
    Re: John McCarthy died today. Kleuskes & Moos <kleuske@somewhere.else.net> - 2011-10-25 09:27 +0000
    Re: John McCarthy died today. Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-10-25 11:27 +0100
    Re: John McCarthy died today. Ark <akhasin@macroexpressions.com> - 2011-10-29 13:33 -0400
      Re: John McCarthy died today. Willem <willem@toad.stack.nl> - 2011-10-29 17:51 +0000
        Re: John McCarthy died today. Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2011-10-29 21:28 +0300
        Re: John McCarthy died today. Keith Thompson <kst-u@mib.org> - 2011-10-29 11:57 -0700
          Re: John McCarthy died today. Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-10-30 08:20 -0700
        Re: John McCarthy died today. Ark <akhasin@macroexpressions.com> - 2011-11-04 05:20 -0400
          Re: John McCarthy died today. Kaz Kylheku <kaz@kylheku.com> - 2011-11-04 15:53 +0000
            Re: John McCarthy died today. James Kuyper <jameskuyper@verizon.net> - 2011-11-04 12:16 -0400
              Re: John McCarthy died today. Kaz Kylheku <kaz@kylheku.com> - 2011-11-04 17:58 +0000
                Re: John McCarthy died today. James Kuyper <jameskuyper@verizon.net> - 2011-11-04 20:49 -0400
                  Re: John McCarthy died today. Kaz Kylheku <kaz@kylheku.com> - 2011-11-05 01:55 +0000
                    Re: John McCarthy died today. "BartC" <bc@freeuk.com> - 2011-11-07 10:54 +0000
                      Re: John McCarthy died today. "Charles Richmond" <netnews@aquaporin4.com> - 2011-11-07 07:36 -0600
                      Re: John McCarthy died today. Kaz Kylheku <kaz@kylheku.com> - 2011-11-07 19:49 +0000
                        Re: John McCarthy died today. James Kuyper <jameskuyper@verizon.net> - 2011-11-07 15:49 -0500
                          Re: John McCarthy died today. Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-11-08 00:38 -0800
                            Re: John McCarthy died today. James Kuyper <jameskuyper@verizon.net> - 2011-11-08 07:05 -0500
                              Re: John McCarthy died today. lawrence.jones@siemens.com - 2011-11-08 09:12 -0500
                              Re: John McCarthy died today. Kaz Kylheku <kaz@kylheku.com> - 2011-11-08 16:48 +0000
                                Re: John McCarthy died today. James Kuyper <jameskuyper@verizon.net> - 2011-11-08 12:12 -0500
                                  Re: John McCarthy died today. Kaz Kylheku <kaz@kylheku.com> - 2011-11-08 23:27 +0000
                              Re: John McCarthy died today. Keith Thompson <kst-u@mib.org> - 2011-11-08 14:10 -0800
                                Re: John McCarthy died today. James Kuyper <jameskuyper@verizon.net> - 2011-11-08 17:16 -0500
                                  Re: John McCarthy died today. lawrence.jones@siemens.com - 2011-11-09 13:51 -0500
                                  Re: Looping Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2011-11-09 19:21 -0700
                                    Re: Looping Kaz Kylheku <kaz@kylheku.com> - 2011-11-10 02:34 +0000
                                Re: John McCarthy died today. Joe Wright <joewwright@comcast.net> - 2011-11-08 17:49 -0500
                                  Re: John McCarthy died today. Keith Thompson <kst-u@mib.org> - 2011-11-08 16:35 -0800
                                    Re: John McCarthy died today. Joe Wright <joewwright@comcast.net> - 2011-11-09 01:08 -0500
                                      Re: John McCarthy died today. Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-11-09 01:26 -0800
                                        Re: John McCarthy died today. Joe Wright <joewwright@comcast.net> - 2011-11-09 08:18 -0500
                                          Re: John McCarthy died today. Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-11-09 05:32 -0800
                              Re: John McCarthy died today. Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-11-09 01:24 -0800
                                Re: John McCarthy died today. Quentin Carbonneaux <qcarbonn@invalid.com> - 2011-11-09 11:59 +0000
                                  Re: John McCarthy died today. Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-11-09 05:34 -0800
                        Re: John McCarthy died today. Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2011-11-08 18:31 +0200
                      Re: John McCarthy died today. Keith Thompson <kst-u@mib.org> - 2011-11-07 14:06 -0800
                        Re: John McCarthy died today. "BartC" <bc@freeuk.com> - 2011-11-08 02:01 +0000
                          Re: John McCarthy died today. Keith Thompson <kst-u@mib.org> - 2011-11-07 23:16 -0800
                        Re: John McCarthy died today. Kaz Kylheku <kaz@kylheku.com> - 2011-11-08 05:18 +0000
                          Re: John McCarthy died today. Keith Thompson <kst-u@mib.org> - 2011-11-07 23:17 -0800
                        Re: John McCarthy died today. Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-11-08 01:46 -0800
                          Re: John McCarthy died today. "BartC" <bc@freeuk.com> - 2011-11-08 13:02 +0000
                          Re: John McCarthy died today. Keith Thompson <kst-u@mib.org> - 2011-11-08 14:19 -0800
                            Re: John McCarthy died today. Edward Rutherford <edward.p.rutherford79@REMOVETHIS.gmail.com> - 2011-11-08 22:23 +0000
                              Re: John McCarthy died today. James Kuyper <jameskuyper@verizon.net> - 2011-11-08 18:13 -0500
                                Re: John McCarthy died today. Kaz Kylheku <kaz@kylheku.com> - 2011-11-08 23:38 +0000
                              Re: John McCarthy died today. Kaz Kylheku <kaz@kylheku.com> - 2011-11-08 23:18 +0000
                                Re: John McCarthy died today. Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2011-11-10 12:40 +0200
                                  Re: John McCarthy died today. Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-11-10 11:39 +0000
                                  Re: John McCarthy died today. "BartC" <bc@freeuk.com> - 2011-11-10 12:23 +0000
                                    Re: John McCarthy died today. 88888 Dihedral <dihedral88888@googlemail.com> - 2011-11-10 05:38 -0800
                                    Re: John McCarthy died today. Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2011-11-10 17:29 +0200
                                    Re: John McCarthy died today. David Thompson <dave.thompson2@verizon.net> - 2011-11-21 02:39 -0500
                              Re: John McCarthy died today. Keith Thompson <kst-u@mib.org> - 2011-11-08 16:34 -0800
                                Re: John McCarthy died today. Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-11-09 01:37 -0800
                                  Re: John McCarthy died today. Keith Thompson <kst-u@mib.org> - 2011-11-09 13:25 -0800
                                    Re: John McCarthy died today. Ian Collins <ian-news@hotmail.com> - 2011-11-10 10:36 +1300
                                    Re: John McCarthy died today. Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-11-09 23:47 -0800
                                    Re: John McCarthy died today. Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-11-10 00:21 -0800
                                      Re: John McCarthy died today. Keith Thompson <kst-u@mib.org> - 2011-11-10 03:04 -0800
                                        Re: John McCarthy died today. gazelle@shell.xmission.com (Kenny McCormack) - 2011-11-10 15:20 +0000
                                          Re: John McCarthy died today. Jorgen Grahn <grahn+nntp@snipabacken.se> - 2011-11-12 23:22 +0000
                                            Re: John McCarthy died today. Kaz Kylheku <kaz@kylheku.com> - 2011-11-13 01:44 +0000
                                              Re: John McCarthy died today. "Charles Richmond" <netnews@aquaporin4.com> - 2011-11-13 04:18 -0600
                                                Re: John McCarthy died today. Kaz Kylheku <kaz@kylheku.com> - 2011-11-13 16:57 +0000
                                                  Re: John McCarthy died today. Robert Wessel <robertwessel2@yahoo.com> - 2011-11-13 11:59 -0600
                                                  Re: John McCarthy died today. gazelle@shell.xmission.com (Kenny McCormack) - 2011-11-13 18:54 +0000
                                                  Re: John McCarthy died today. Keith Thompson <kst-u@mib.org> - 2011-11-13 14:47 -0800
                                                    Re: John McCarthy died today. Kaz Kylheku <kaz@kylheku.com> - 2011-11-14 03:43 +0000
                                                      Re: John McCarthy died today. Ike Naar <ike@sverige.freeshell.org> - 2011-11-14 09:00 +0000
                                                        Re: John McCarthy died today. Kaz Kylheku <kaz@kylheku.com> - 2011-11-14 18:30 +0000
                                                          Re: John McCarthy died today. James Kuyper <jameskuyper@verizon.net> - 2011-11-14 14:44 -0500
                                                          Re: John McCarthy died today. Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-11-14 20:13 +0000
                                                  Re: John McCarthy died today. Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-11-14 00:21 -0800
                                      Re: John McCarthy died today. Lauri Alanko <la@iki.fi> - 2011-11-10 15:26 +0000
                                  Re: John McCarthy died today. Kaz Kylheku <kaz@kylheku.com> - 2011-11-10 01:51 +0000
                                Re: John McCarthy died today. Edward Rutherford <edward.p.rutherford79@REMOVETHIS.gmail.com> - 2011-11-09 17:15 +0000
                                  Re: John McCarthy died today. "BartC" <bc@freeuk.com> - 2011-11-09 18:04 +0000
                                    Re: John McCarthy died today. Keith Thompson <kst-u@mib.org> - 2011-11-09 13:31 -0800
                                      Re: John McCarthy died today. Robert Wessel <robertwessel2@yahoo.com> - 2011-11-09 15:53 -0600
                                      Re: John McCarthy died today. "BartC" <bc@freeuk.com> - 2011-11-09 22:02 +0000
                                        Re: John McCarthy died today. Keith Thompson <kst-u@mib.org> - 2011-11-09 14:14 -0800
                                  Re: John McCarthy died today. Keith Thompson <kst-u@mib.org> - 2011-11-09 13:50 -0800
                        Re: John McCarthy died today. James Kuyper <jameskuyper@verizon.net> - 2011-11-08 07:10 -0500
            Re: John McCarthy died today. Keith Thompson <kst-u@mib.org> - 2011-11-04 14:51 -0700

Page 2 of 5 — ← Prev page 1 [2] 3 4 5  Next page →

#12885

On 11/08/2011 03:38 AM, Nick Keighley wrote:
> 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 ();
>     }

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

[toc] | [prev] | [next] | [standalone]

#12893

James Kuyper <jameskuyper@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

[toc] | [prev] | [next] | [standalone]

#12899

On 2011-11-08, James Kuyper <jameskuyper@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! :)

[toc] | [prev] | [next] | [standalone]

#12902

On 11/08/2011 11:48 AM, Kaz Kylheku wrote:
> On 2011-11-08, James Kuyper <jameskuyper@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).
...
> 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.

[toc] | [prev] | [next] | [standalone]

#12930

On 2011-11-08, James Kuyper <jameskuyper@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; )
  {
  }

:)

[toc] | [prev] | [next] | [standalone]

#12916

James Kuyper <jameskuyper@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);
}

-- 
Keith Thompson (The_Other_Keith) kst-u@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"

[toc] | [prev] | [next] | [standalone]

#12918

On 11/08/2011 05:10 PM, Keith Thompson wrote:
> James Kuyper <jameskuyper@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.

[toc] | [prev] | [next] | [standalone]

#12977

James Kuyper <jameskuyper@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

[toc] | [prev] | [next] | [standalone]

#12999 — Re: Looping

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

> James Kuyper <jameskuyper@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;
}

[toc] | [prev] | [next] | [standalone]

#13000 — Re: Looping

On 2011-11-10, Joe Pfeiffer <pfeiffer@cs.nmsu.edu> wrote:
> ram@zedat.fu-berlin.de (Stefan Ram) writes:
>
>> James Kuyper <jameskuyper@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;
> }

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.

[toc] | [prev] | [next] | [standalone]

#12925

On 11/8/2011 17:10, Keith Thompson wrote:
> James Kuyper<jameskuyper@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."

[toc] | [prev] | [next] | [standalone]

#12936

Joe Wright <joewwright@comcast.net> writes:
> On 11/8/2011 17:10, Keith Thompson wrote:
>> James Kuyper<jameskuyper@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.

-- 
Keith Thompson (The_Other_Keith) kst-u@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"

[toc] | [prev] | [next] | [standalone]

#12940

On 11/8/2011 19:35, Keith Thompson wrote:
> Joe Wright<joewwright@comcast.net>  writes:
>> On 11/8/2011 17:10, Keith Thompson wrote:
>>> James Kuyper<jameskuyper@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.

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

[toc] | [prev] | [next] | [standalone]

#12945

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

[toc] | [prev] | [next] | [standalone]

#12959

On 11/9/2011 04:26, Nick Keighley wrote:
> 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"?
Edsger Dijkstra, proponent of structured programming.


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

[toc] | [prev] | [next] | [standalone]

#12960

On Nov 9, 1:18 pm, Joe Wright <joewwri...@comcast.net> wrote:
> On 11/9/2011 04:26, Nick Keighley wrote:
>
>
>
> > 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"?
>
> Edsger Dijkstra, proponent of structured programming.

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

[toc] | [prev] | [next] | [standalone]

#12944

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)


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.

[toc] | [prev] | [next] | [standalone]

#12954

On 2011-11-09, Nick Keighley <nick_keighley_nospam@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

[toc] | [prev] | [next] | [standalone]

#12963

On Nov 9, 11:59 am, Quentin Carbonneaux <qcarb...@invalid.com> wrote:
> On 2011-11-09, Nick Keighley <nick_keighley_nos...@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...

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

[toc] | [prev] | [next] | [standalone]

#12898

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

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

[toc] | [prev] | [next] | [standalone]

Page 2 of 5 — ← Prev page 1 [2] 3 4 5  Next page →

Back to top | Article view | comp.lang.c

csiph-web