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?

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?

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

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

> 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

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

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

"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)++
    }

>     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

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