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

On 19/04/2025 19:59, bart wrote:

On 19/04/2025 17:28, Kaz Kylheku wrote:

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

On 19/04/2025 07:27, Janis Papanagnou wrote:

On 19.04.2025 00:27, bart wrote:

>

So, yes, I think that is problematic, and the fault is with the
language. This stuff isn't not hard to get right; even BASIC manages to
FOR-loops properly.

>
As so often explained to you, BASIC has a most primitive loop.[*]

>
As has been so often pointed out, the vast majority of iterating loops
can be accommodated by 'for i = a to b'. So in that case it is not
primitive.
>
However C's for-loop genuinely *IS* primitve.

>
The abstraction level difference is very small between a loop which
supplies only holes where you plug in your tests and increments, and a
loop which sets up the tests and increments.
>
(In this particular case, we can macro over the difference with
a primitve token-replacing preprocessor.)

 That's writing your own language on top. You shouldn't need to that to be able to use fundamental features!
 

If that's all you can intellectually handle you're obviously a lousy
programmer (and far from a software engineer).

>
Do you undertand my reasons for saying what I do?
>
Suppose that C had both its primitive loop, and one like Basic's (or
like Awk's); would that be better? If so, why?

>
We've shown that with preprocessing it does:
>
#define for_range(var, from, to) ...
>
it's hard to define it so that it is absolutely correct,
able to handle an int variable going up to INT_MAX.

 But, nobody really cares about that. I say more about this later.
 

>

In fact, WHY does Awk have that other kind of loop? Since the primitive
form can express it just as well.

>
No, it cannot. The Awk  for (x in array) loop is not easily
reproduced with the regular for loop.
>
It has to step x through the keys of the associative array.
>
To do it with a low level loop, we need the primitive stepping
operations:
>
    for (iter = array_first(array);
         array_more(iter) && key = array_get(iter)
         iter = array_next(iter))
    {
       # key is set to successive keys
    }
>
Not only is this extremely clumsy, but those operations
don't even exist. There is no associative array iterating
object!

 I took the example of Awk that was using 'for in' and wrote it like this:
    split ("one two three four five", table)
    for (i=1; i<=5; i++)
       print i, table[i]
 It seemed to work. That it may have unrelated issues with associative arrays is another matter.
 

In my cppawk project there is a predefined keys (var, array) clause you
can use in the loop macro.
>
Under the hood, this actually obtains a list of the keys as a Lisp-like
list, and then iterates over that. (Other approaches could be used,
like a function which converts the *keys* of a given array into
the *values* of a new array, that new array being indexed numerically
from zero. We could then step over these with i = 0 ... i++.

 In my script language I can get a helper function to produce a linear list of keys then iterate over that with a regular loop.
 My original example used an array of strings, which JP changed to an Awk table in order to show off Awk's 'for in'. They haven't yet explained why a normal loop and normal indexing work.
 

I've written many 10s of 1000s of lines of assembly. But I prefer HLL
code, and HLL code which has some must-have fundamentals. Like a fucking
loop that works.

>
But you yourself wrote such a loop that is broken; it has undefined
behavior when you go to the maximum value of the signed type.

 The behaviour is defined: it wraps round and the loop keeps going.
 But even if it went nowhere near the limits of the type, such a loop could keep going for a lifetime given a large enough range.
 You don't seem that bothered about that. In both cases the user would have to abort the program.
 

That's worse than a 100% correct primitive loop in which if such a
situation occurs, it is in plain sight, caused by the expressions
the programmer chose to plug into it.
>
I told you I would rub this in your face!

 As I said, I don't care. Few people do, especially if working with 64 bits.

I tried this on two online Awks:
BEGIN {
     split ("one two three four five", table)
   for (i=9223372036854775800; i<=9223372036854775806; i++)
       print i
    }
Both went funny, and the limit isn't even on i63.max.
I don't know what type 'i' is, but it seems fine with i32.max or u32.max, so I assume it's something like 2**52 (typical when f64 represents integers).
Whatever, it's giving unexpected results, whether it's due to hitting i64.max or reaching a threshold where a simple increment runs out of precision bits. As I said, few care.