Re: Loops (was Re: do { quit; } else { })

On 17/04/2025 00:49, Kaz Kylheku wrote:

On 2025-04-16, bart <bc@freeuk.com> wrote:

On 16/04/2025 22:43, Kaz Kylheku wrote:

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.

>
I'm not exactly sure what you are asking. Is it a loop like this, here
in my language:
>
      int n:=0
>
      for i in i32.bounds do          # ie. i32.min .. i32.max
          ++n
      od
>
      println n
>
This works fine; after a second or so it displays 4294967296.
>
However, this languages evaluates using 64 bits. Perhaps this loop may
demonstrate the issues better:
>
      for i in i64.bounds do
>
However, I would estimate it would take 190 years to finish.

 Sure, but you could have a loop that goes over the last n
values of the range of i64, for a reasonably small n.
 

I assume you're thinking of C which uses i32 and where comparisons near
the extreme values of the type are problemetical. Or this line in my

 Comparisons aren't; gratuitous increments or displacements are.

OK, I've had a look in detail at the code I generate for for-loops.
I believe it can be made to work with a test for equality instead of less-than-equal, with the increment done only if unequal. But it's slightly more elaborate.
It works because, for variable limits for example, it already does a one-time "<=" check before it enters the loop.
But there is a restriction: the loop index can't be changed by user code within the loop. (Otherwise it can have a value beyond the limit, and won't detect that.)
As it happens, my loop indices are usually immutable, but not always. So the revised loop handling can be limited to the case when the index /is/ immutable.
However, I'm not going to implement that. It's enough to know it is a possibility. This particular issue has not bothered me over 43 years of using <= compares, even when my ints were only 16 bits; I doubt it will bite any time soon.