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

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 also said I worked out how to fix it in my language, but won't be doing so since it changes the language spec a little, and doesn't help with the other problem mentioned above, which is to do with sanitising for-loop ranges.
This is more to do with user code, not language.