Path: ...!news.misty.com!weretis.net!feeder9.news.weretis.net!news.quux.org!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: Kaz Kylheku <643-408-1753@kylheku.com>
Newsgroups: comp.lang.c
Subject: Re: Loops (was Re: do { quit; } else { })
Date: Sat, 19 Apr 2025 16:28:25 -0000 (UTC)
Organization: A noiseless patient Spider
Lines: 91
Message-ID: <20250419090525.701@kylheku.com>
References: <vspbjh$8dvd$1@dont-email.me> <vt94q5$3jjod$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>
Injection-Date: Sat, 19 Apr 2025 18:28:26 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="6d4a4d914b9b010fce7e1ec0cf5d3dd8";
	logging-data="1895723"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18mZRs/a5EqieltG4OCxbgVZjYpgB5A0Aw="
User-Agent: slrn/pre1.0.4-9 (Linux)
Cancel-Lock: sha1:6WtfqGVsdk++46CzTEGuykUsx2Y=
Bytes: 5202

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.)

>> 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.

> 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!

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++.

It's all pretty inefficient.

As you can see, it's practically a necessity for awk to have that for/in
iteration method.

> 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.

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!

-- 
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca