Sujet : Re: Loops (was Re: do { quit; } else { })
De : 643-408-1753 (at) *nospam* kylheku.com (Kaz Kylheku)
Groupes : comp.lang.cDate : 16. Apr 2025, 22:43:38
Autres entêtes
Organisation : A noiseless patient Spider
Message-ID : <20250416142925.663@kylheku.com>
References : 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
User-Agent : slrn/pre1.0.4-9 (Linux)
On 2025-04-16, bart <
bc@freeuk.com> wrote:
On 16/04/2025 06:35, Janis Papanagnou wrote:
On 15.04.2025 22:46, bart wrote:
On 15/04/2025 20:07, Scott Lurndal wrote:
[...]
Real for loops _are_ a three-way construct.
>
[...]
>
Any step other than 1 is unusual. [...]
>
Nonsense. Arithmetic loop steps other than one are noting unusual
and been supported by programming languages (and also been used)
since decades in programming.
>
So what are you claiming, that the majority of loops in any given
program will have steps other than +1 or -1?
Hey Bart, how would you handle a loop like
do x = m to n ...
where m and n are not known until run time, and may be the
extreme values of the type? Like C's INT_MIN and INT_MAX, respectively,
where x is of type int.
Because in this loop, x takes on every possible value of the type,
we cannot have a loop guard which prevents entry of the loop body
based on solely the value of x.
The compilaton strategy we will likely pursue for this will be
a bottom-of-the-loop test. That is to say, after executing
an iteration, if x has the value n, then the loop terminates.
Unfortunately, this pattern doesn't lend itself well to the
for(;;) construct n C.
The idiom for (x = m; x <= n; x++) only works when x may be
incremented even when it is already equal to n.
If the type is singned, like int, and n is INT_MAX, x++
is undefined behavior after the last iteration.
So this is part of the reason why for leaves everything open; the C
programmer can hand-wave away these issues based on the specific use
case of the loop, whose details are in the open, making it obvious that
the idiom doesn't fully generalize to every corner case.
The for construct could use a way of indicating a bottom test,
like, oh, I don't know:
for (decl/expr; : expr ; expr) // or some better way
Here, the : means, jump unconditionally into the first iteration,
and test expr after each iteration, before doing the increment.
Then we can do
for (int i = INT_MIN; : i < INT_MAX; i++)
After the last iteration, i is INT_MAX, and so the test fails.
The loop terminates without performing i++.
-- TXR Programming Language: http://nongnu.org/txrCygnal: Cygwin Native Application Library: http://kylheku.com/cygnalMastodon: @Kazinator@mstdn.ca