www.digitalmars.com         C & C++   DMDScript  

D - do..until() ?

reply "Pavel \"EvilOne\" Minayev" <evilone omen.ru> writes:
Why not? Pascal has the equivalent structure, so
does BASIC...

Just why do we have to type something like:

    do
    {
        ...
    } while (!(flag1 || flag2 && flag3));

Instead of:


    do
    {
        ...
    } until (flag1 || flag2 && flag3);

On other hand, that requires an additional keyword.
Anyhow, what do you think of this?
Nov 06 2001
next sibling parent reply "Pavel \"EvilOne\" Minayev" <evilone omen.ru> writes:
One more thing... I never liked the for(;;) way to
define an infinite loop. while(true) works, of course,
but I'd personally would prefer a special form for
this case - like, say, Suneido employs "forever"
keyword:

    forever
    {
        ...
    }

Or maybe "while()" - with empty braces?
Nov 06 2001
next sibling parent reply "Walter" <walter digitalmars.com> writes:
I always liked
    while(1)
myself, but many compilers go into spam mode when they see that.

"Pavel "EvilOne" Minayev" <evilone omen.ru> wrote in message
news:9s9fsf$267d$1 digitaldaemon.com...
 One more thing... I never liked the for(;;) way to
 define an infinite loop. while(true) works, of course,
 but I'd personally would prefer a special form for
 this case - like, say, Suneido employs "forever"
 keyword:

     forever
     {
         ...
     }

 Or maybe "while()" - with empty braces?

Nov 06 2001
parent reply "Pavel \"EvilOne\" Minayev" <evilone omen.ru> writes:
"Walter" <walter digitalmars.com> wrote in message
news:9s9r4s$2djk$3 digitaldaemon.com...

 I always liked
     while(1)
 myself, but many compilers go into spam mode when they see that.

I usually use while(true). However, making a special form for this would (IMHO) both make the code more readable and ease things for the compiler.
Nov 07 2001
parent "Walter" <walter digitalmars.com> writes:
"Pavel "EvilOne" Minayev" <evilone omen.ru> wrote in message
news:9sasus$9se$1 digitaldaemon.com...
 "Walter" <walter digitalmars.com> wrote in message
 news:9s9r4s$2djk$3 digitaldaemon.com...
 I always liked
     while(1)
 myself, but many compilers go into spam mode when they see that.

this would (IMHO) both make the code more readable and ease things for the compiler.

I would have agreed with you years ago, but I am just so used to the various idioms like while(1) that they seem more understandable to me.
Nov 09 2001
prev sibling parent reply "Robert W. Cunningham" <rwc_2001 yahoo.com> writes:
Pavel \"EvilOne\" Minayev wrote:

 One more thing... I never liked the for(;;) way to
 define an infinite loop. while(true) works, of course,
 but I'd personally would prefer a special form for
 this case - like, say, Suneido employs "forever"
 keyword:

     forever
     {
         ...
     }

 Or maybe "while()" - with empty braces?

Here's what I use in C: #define EVER ;; for (EVER) { blah(); } Even if the #define is missed, or is hidden away, a C programmer "knows" what "EVER" should mean (especially since I like my macros and defines in caps). And a non-C programmer can get the gist of what's going on just from the text. I have friends who prefer something like: #define forever for(;;) forever { fubar(); } This doesn't appeal to me because it changes the visible syntax of the language (even if it is in a "good way"), since it appears to add yet another loop control mechanism to a language that doesn't possess one. And it (IMHO) is one of the worst possible uses for the preprocessor (and one of the best reasons to eliminate it). If you really want to modify a language, be explicit about it by using a completely separate tool, such as M4. I'm not against a language having lots and lots of keywords, just so long as both the meaning and use are "natural": They should simply help the code "read" better, even (especially) to non-experts (Ada did this especially well, but at a cost). Such keywords should NOT make the language more complex (ala C++) or obtuse. I suppose this is the hardest part of language design, and I'm always in awe of those who can create "elegant and expressive" languages that are also "easy and simple". UCSD Pascal, Scheme, Ruby and much of the Bash shell scripting language are some of my favorites, each for different reasons. I suspect (and hope) I will soon be adding D to that list. The whole notion of the infinite loop bothers me, since very few are truly infinite! Most "supposedly" infinite loops are simply loops for which no single test condition could be determined, or the loop wraps spaghetti code that has several exit paths. The only "real" infinite loops I recall seeing have been in the scheduler for preemptive OSes and the equivalent event handlers for non-preemptive OSes and GUIs. Most other infinite loops probably could have been refactored to eliminate the infinite loop. State machines are often the worst offenders in this area. Still, saying it could be refactored doesn't mean it will be, which means we will probably want a clean and simple infinite loop construct just to make such loops stick out a bit more, and to make it extra-clear exactly what's going on. This probably goes under that category of language features called "Truly Useful Syntactic Sugar". However, if an explicit infinite loop construct is added to D, then I'd strongly recommend that it be made VERY difficult to construct an infinite loop any other way, at least not trivially. Loop control problems are among the most common in any language (especially the chronic off-by-1 errors), and if D can help prevent, minimize and reveal such errors, it will be doing all of us a great service. Forbid constants or literals to be used as loop control variables ("while(1)"), and require that any variable used to control a loop must be modified either within the loop control structure, or within the loop body, or must be typed something like "volatile" or "global" (and the compiler should check that any such variable is indeed modified somewhere in the code). Somehow, my $0.02 is still in my pocket... -BobC
Nov 06 2001
parent reply "Pavel \"EvilOne\" Minayev" <evilone omen.ru> writes:
"Robert W. Cunningham" <rwc_2001 yahoo.com> wrote in message
news:3BE8A500.3D56BF70 yahoo.com...

 I'm not against a language having lots and lots of keywords, just so
 long as both the meaning and use are "natural":  They should simply help
 the code "read" better, even (especially) to non-experts (Ada did this
 especially well, but at a cost).

Indeed. And I think that's exactly the case.
 I suppose this is the hardest part of language design, and I'm always in
 awe of those who can create "elegant and expressive" languages that are
 also "easy and simple".  UCSD Pascal, Scheme, Ruby and much of the Bash
 shell scripting language are some of my favorites, each for different
 reasons.  I suspect (and hope) I will soon be adding D to that list.

 The whole notion of the infinite loop bothers me, since very few are
 truly infinite!  Most "supposedly" infinite loops are simply loops for
 which no single test condition could be determined, or the loop wraps
 spaghetti code that has several exit paths.  The only "real" infinite
 loops I recall seeing have been in the scheduler for preemptive OSes and
 the equivalent event handlers for non-preemptive OSes and GUIs.  Most
 other infinite loops probably could have been refactored to eliminate
 the infinite loop.  State machines are often the worst offenders in this
 area.

Well sometimes it's just easier to make the loop run "forever", and do all the breaking inside. In fact, there are situations when this form is much more readable than complex logical expressions serving as breaking conditions for while()... besides, if you want to do both pre- and post-checking, you still have to do some breaking inside. I agree that most so-called "infinite" loops aren't actually infinite, so the keyword "forever" doesn't suite well... "loop" maybe?
 Still, saying it could be refactored doesn't mean it will be, which
 means we will probably want a clean and simple infinite loop construct
 just to make such loops stick out a bit more, and to make it extra-clear
 exactly what's going on.  This probably goes under that category of
 language features called "Truly Useful Syntactic Sugar".

Yes!!!
 However, if an explicit infinite loop construct is added to D, then I'd
 strongly recommend that it be made VERY difficult to construct an
 infinite loop any other way, at least not trivially.  Loop control
 problems are among the most common in any language (especially the
 chronic off-by-1 errors), and if D can help prevent, minimize and reveal
 such errors, it will be doing all of us a great service.  Forbid
 constants or literals to be used as loop control variables ("while(1)"),
 and require that any variable used to control a loop must be modified
 either within the loop control structure, or within the loop body, or
 must be typed something like "volatile" or "global" (and the compiler
 should check that any such variable is indeed modified somewhere in the
 code).

Forbidding to use constants in while() loops seems logical if we have a special form of "infinite" loop. The second part - checking loop control variables to be modified - is not that simple, however; don't forget about threads, not to mention pointers to variables and pointers to functions. Imagine something like that: int i = 0; int* p; ... // somewhere in conditional statement, so compiler // can't be sure it gets executed p = &i; ... while (i < 10) { // how does compiler know that we modify i? (*p)++ }
Nov 07 2001
next sibling parent reply Axel Kittenberger <axel dtone.org> writes:
     while (i < 10)
     {
         // how does compiler know that we modify i?
         (*p)++
     }

The compiler knows and expects that i is not modified in the loop, if it can be modified by another thread, by the kernel, in an interrupt or directly by hardware it has to be declared as volatile. - Axel
Nov 07 2001
parent reply "Pavel \"EvilOne\" Minayev" <evilone omen.ru> writes:
"Axel Kittenberger" <axel dtone.org> wrote in message
news:9sb15k$ckm$1 digitaldaemon.com...
     while (i < 10)
     {
         // how does compiler know that we modify i?
         (*p)++
     }

The compiler knows and expects that i is not modified in the loop, if it can be modified by another thread, by the kernel, in an interrupt or directly by hardware it has to be declared as volatile.

Okay, this solves the problem with threads. But what about the given sample with pointers? Here, it's the same thread that modifies the variable... yet compiler won't be able to detect that and will give a compiler error where it shoudln't. Of course, it is possible to declare variable as volatile in this case as well, but why should we since it affects optimization of other places where the variable can occur as well?
Nov 07 2001
parent reply "Robert W. Cunningham" <rwc_2001 yahoo.com> writes:
Pavel \"EvilOne\" Minayev wrote:

 "Axel Kittenberger" <axel dtone.org> wrote in message
 news:9sb15k$ckm$1 digitaldaemon.com...
     while (i < 10)
     {
         // how does compiler know that we modify i?
         (*p)++
     }

The compiler knows and expects that i is not modified in the loop, if it can be modified by another thread, by the kernel, in an interrupt or directly by hardware it has to be declared as volatile.

Okay, this solves the problem with threads. But what about the given sample with pointers? Here, it's the same thread that modifies the variable... yet compiler won't be able to detect that and will give a compiler error where it shoudln't. Of course, it is possible to declare variable as volatile in this case as well, but why should we since it affects optimization of other places where the variable can occur as well?

In the above case, the compiler should complain that the loop control variable isn't being directly modified, even though it *is* being modified indirectly. Simply outlaw this kind of situation by halting compilation, or at least issue a strongly worded warning. -BobC
Nov 07 2001
next sibling parent "Robert W. Cunningham" <rwc_2001 yahoo.com> writes:
"Robert W. Cunningham" wrote:

 Pavel \"EvilOne\" Minayev wrote:

 "Axel Kittenberger" <axel dtone.org> wrote in message
 news:9sb15k$ckm$1 digitaldaemon.com...
     while (i < 10)
     {
         // how does compiler know that we modify i?
         (*p)++
     }

The compiler knows and expects that i is not modified in the loop, if it can be modified by another thread, by the kernel, in an interrupt or directly by hardware it has to be declared as volatile.

Okay, this solves the problem with threads. But what about the given sample with pointers? Here, it's the same thread that modifies the variable... yet compiler won't be able to detect that and will give a compiler error where it shoudln't. Of course, it is possible to declare variable as volatile in this case as well, but why should we since it affects optimization of other places where the variable can occur as well?

In the above case, the compiler should complain that the loop control variable isn't being directly modified, even though it *is* being modified indirectly. Simply outlaw this kind of situation by halting compilation, or at least issue a strongly worded warning.

Well, maybe for everything other than char* (see my post in the closures thread)... -BobC
Nov 07 2001
prev sibling parent "Pavel \"EvilOne\" Minayev" <evilone omen.ru> writes:
"Robert W. Cunningham" <rwc_2001 yahoo.com> wrote in message
news:3BE9E9A3.9B0F2BC5 yahoo.com...

 In the above case, the compiler should complain that the loop control
 variable isn't being directly modified, even though it *is* being modified
 indirectly.  Simply outlaw this kind of situation by halting compilation,

 at least issue a strongly worded warning.

Why??? The loop IS correct, there's nothing really bad with it, why should the compiler complain?
Nov 07 2001
prev sibling parent reply Russell Borogove <kaleja estarcion.com> writes:
I'm just going to cast my vote at this point for not changing 
the language in any way to support forever-loops. IMO, existing
facilities in C, C++, and D are sufficient, well known, and 
compatible across all three languages.

-RB
Nov 07 2001
parent "Pavel \"EvilOne\" Minayev" <evilone omen.ru> writes:
"Russell Borogove" <kaleja estarcion.com> wrote in message
news:3BE98064.DDC95275 estarcion.com...

 I'm just going to cast my vote at this point for not changing
 the language in any way to support forever-loops. IMO, existing

If while(true) is not a forever-loop, then what is it? So is while(1). So is while(-666.123). So is... So it's supported in C, C++ and D already. =) What I want is a clear way to distinguish the "forever-loop" from anything else - just something that makes program easier to read. Syntactic sugar as well.
 facilities in C, C++, and D are sufficient, well known, and
 compatible across all three languages.

D program with more than hundred lines of code is very unlikely to be compiled by any C++ compiler, I believe; besides, apart from possible conflicts with variables called "forever", I don't see any compatibility problems - since one can always use while(true). As for sufficiecy... a long topic, indeed, but the only thing that I can remind of here is that ++ and -- operators don't satisfy this requirement as well...
Nov 07 2001
prev sibling parent reply Axel Kittenberger <axel dtone.org> writes:
 Why not? Pascal has the equivalent structure, so
 does BASIC...

In Pascal it is REPEAT ... UNTIL [break-condition]; not do-until. - Axel -- |D) http://www.dtone.org
Nov 06 2001
parent "Pavel \"EvilOne\" Minayev" <evilone omen.ru> writes:
"Axel Kittenberger" <axel dtone.org> wrote in message
news:9sajlp$1a6$1 digitaldaemon.com...

 In Pascal it is
 REPEAT
   ...
 UNTIL [break-condition];

 not do-until.

I know. In BASIC, it's DO..LOOP UNTIL. But since the meaning is the same, who cares? I just wanted it to suite the existing D syntax better.
Nov 07 2001