Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: bart <bc@freeuk.com>
Newsgroups: comp.lang.c
Subject: Re: Loops (was Re: do { quit; } else { })
Date: Sat, 19 Apr 2025 19:59:03 +0100
Organization: A noiseless patient Spider
Lines: 125
Message-ID: <vu0rpm$22n7b$1@dont-email.me>
References: <vspbjh$8dvd$1@dont-email.me> <vt9628$3hhr8$3@dont-email.me>
 <vtammh$174ev$1@dont-email.me> <vtavn9$1dp7m$3@dont-email.me>
 <vtb8nv$1plb2$2@dont-email.me> <vtba81$1qfbm$1@dont-email.me>
 <vtbc6o$1te2o$1@dont-email.me> <vtbhjv$24api$1@dont-email.me>
 <vtbn2k$293r1$1@dont-email.me> <vtc19j$2kqlj$1@dont-email.me>
 <87a58mqt2o.fsf@nosuchdomain.example.com> <vtc7mp$2q5hr$1@dont-email.me>
 <vtcqf6$3j95s$1@dont-email.me> <vtdh4q$b3kt$1@dont-email.me>
 <vtf7fe$1qtpg$1@dont-email.me> <vtgfuf$31ug1$1@dont-email.me>
 <20250413072027.219@kylheku.com> <vtgpce$39229$1@dont-email.me>
 <vti2ki$g23v$1@dont-email.me> <vtin99$vu24$1@dont-email.me>
 <vtiuf0$18au8$1@dont-email.me> <vtj97r$1i3v3$1@dont-email.me>
 <vtl166$36p6b$1@dont-email.me> <vtlcg0$3f46a$2@dont-email.me>
 <vtnekn$1fogv$1@dont-email.me> <vto2mb$20c4n$1@dont-email.me>
 <vtu4i5$3hteg$1@dont-email.me> <vtujko$3uida$1@dont-email.me>
 <vtvfop$rf2p$1@dont-email.me> <vtvto2$15otp$1@dont-email.me>
 <20250419090525.701@kylheku.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Sat, 19 Apr 2025 20:59:03 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="5c7860f03a8e4f1e49f90b82bdb5768f";
	logging-data="2186475"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+vj2vGian1f84ohAmdhWBF"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:TONIz+s5oszUAJWKPd7OVgVIWQc=
In-Reply-To: <20250419090525.701@kylheku.com>
Content-Language: en-GB
Bytes: 6628

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.