D - do..until() ?
- Pavel \"EvilOne\" Minayev (14/14) Nov 06 2001 Why not? Pascal has the equivalent structure, so
- Pavel \"EvilOne\" Minayev (10/10) Nov 06 2001 One more thing... I never liked the for(;;) way to
- Walter (5/15) Nov 06 2001 I always liked
- Pavel \"EvilOne\" Minayev (5/8) Nov 07 2001 I usually use while(true). However, making a special form for
- Walter (4/12) Nov 09 2001 I would have agreed with you years ago, but I am just so used to the var...
- Robert W. Cunningham (61/71) Nov 06 2001 Here's what I use in C:
- Pavel \"EvilOne\" Minayev (29/64) Nov 07 2001 Indeed. And I think that's exactly the case.
- Axel Kittenberger (4/9) Nov 07 2001 The compiler knows and expects that i is not modified in the loop, if it...
- Pavel \"EvilOne\" Minayev (9/17) Nov 07 2001 Okay, this solves the problem with threads. But what about the given
- Robert W. Cunningham (6/25) Nov 07 2001 In the above case, the compiler should complain that the loop control
- Robert W. Cunningham (4/29) Nov 07 2001 Well, maybe for everything other than char* (see my post in the closures
- Pavel \"EvilOne\" Minayev (5/9) Nov 07 2001 or
- Russell Borogove (5/5) Nov 07 2001 I'm just going to cast my vote at this point for not changing
- Pavel \"EvilOne\" Minayev (16/20) Nov 07 2001 If while(true) is not a forever-loop, then what is it?
- Axel Kittenberger (8/10) Nov 06 2001 In Pascal it is
- Pavel \"EvilOne\" Minayev (5/10) Nov 07 2001 I know. In BASIC, it's DO..LOOP UNTIL. But since the
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
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
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
"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
"Walter" <walter digitalmars.com> "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 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.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 09 2001
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
"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
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
"Axel Kittenberger" <axel dtone.org> wrote in message news:9sb15k$ckm$1 digitaldaemon.com...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?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.
Nov 07 2001
Pavel \"EvilOne\" Minayev wrote:"Axel Kittenberger" <axel dtone.org> wrote in message news:9sb15k$ckm$1 digitaldaemon.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, or at least issue a strongly worded warning. -BobCOkay, 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?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.
Nov 07 2001
"Robert W. Cunningham" wrote:Pavel \"EvilOne\" Minayev wrote:Well, maybe for everything other than char* (see my post in the closures thread)... -BobC"Axel Kittenberger" <axel dtone.org> wrote in message news:9sb15k$ckm$1 digitaldaemon.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, or at least issue a strongly worded warning.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?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.
Nov 07 2001
"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,orat 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
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
"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, existingIf 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
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
"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