Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: Janis Papanagnou <janis_papanagnou+ng@hotmail.com>
Newsgroups: comp.lang.c
Subject: Re: Loops (was Re: do { quit; } else { })
Date: Tue, 22 Apr 2025 09:32:32 +0200
Organization: A noiseless patient Spider
Lines: 111
Message-ID: <vu7gmh$47a0$1@dont-email.me>
References: <vspbjh$8dvd$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> <vu01k7$1bfv2$1@dont-email.me>
 <vu0720$1dva7$1@dont-email.me> <vu2hmg$3jn88$1@dont-email.me>
 <vu2mkc$3noft$1@dont-email.me> <vu38da$735n$1@dont-email.me>
 <vu3j7s$g755$1@dont-email.me> <87ecxmv4t4.fsf@nosuchdomain.example.com>
 <vu401g$reom$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Injection-Date: Tue, 22 Apr 2025 09:32:34 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="68f983528362bbc93f43b109ae23844d";
	logging-data="138560"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX189OEjqleXO4GRZxFFVd53q"
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101
 Thunderbird/45.8.0
Cancel-Lock: sha1:6U+Ye40mlqFKT7WODehvP+rdeRQ=
In-Reply-To: <vu401g$reom$1@dont-email.me>
X-Enigmail-Draft-Status: N1110
Bytes: 5532

On 21.04.2025 01:29, bart wrote:
> On 20/04/2025 23:36, Keith Thompson wrote:
>> bart <bc@freeuk.com> writes:
> 
>>>      for(p=sqliteHashFirst(&pSchema->trigHash); p; p=sqliteHashNext(p)){
>>>          sqlite3DeleteTrigger(db, (Trigger*)sqliteHashData(p));
>>>      }
> 
>>
>> I might write it like this:
>>
>>      for ( p = sqliteHashFirst(&pSchema->trigHash);
>>            p != NULL;
>>            p = sqliteHashNext(p) )
>>      {
>>          sqlite3DeleteTrigger(db, (Trigger*)sqliteHashData(p));
>>      }
> 
>> I have certain preferences (spaces around most operators, explicit
>> comparison to NULL, willingness to split long lines) that other C
>> programmers may or may not share.
> 
> I rarely see complex loops split over multiple lines

(There's obviously a lot you haven't seen.)

> (mainly when they
> get so long that they'd overflow the line, but they can still be complex
> enough before then).
> 
> But the thing is, once you split it into multiple lines, then there is
> little advantage over using a regular 'while' loop:

You still have the controlling elements in one place with 'for'.

> [...]
> 
>>> It keeps it even more together, which you seem to like.
>>
>> That's something you invented.  I find it ugly, and I presume you'd
>> agree.  The fact that you think that someone else would prefer it
>> indicates that you don't understand how other people think.
> 
> AFAIK it is legal C code, and I invented it because somebody said things
> that belong together should be together in one place.

Yes, that's a commonplace. (But "one place" doesn't mean "stuffed" or
"all in one line".)

> However, I have
> seen actual examples like that, in for-headers that that use
> comma-separated expressions.

(You can see and find arbitrary code, better or worse.)

> 
> 
>> I'd rather not write `for (ch in 0..255)` because it's a syntax error.
> 
> It's a syntax error because the form doesn't naturally exist in C; you'd
> have to emulate using macros, which is a poor solution.

Yes, and that's his point; it's not "C".

If I want abstractions I don't (unless I have to) use "C". If I want to
have clean concepts, say iterating over an indexed array, I can use in
"C"

  for (i=0; i<N; i++)
    arr[i] = fun (arr[i]);

which is clean enough for me. But I might prefer (with other languages)
to not care about the bounds in the first place, and use

  for (i := lwb(arr) to upb(arr))    # not "C"
    arr[i] := fun (arr[i]);

if I'd want to avoid errors with the bounds. But the real thing I'd want
is a functional approach where I don't need indices at all

  iterate (arr, fun);    # not "C"

> 
>> You have the luxury of using your own language.
> 
> That 'ch in 0..255' form or close equivalent is supported by that long
> set of languages I listed earlier. It's not my invention, I just copied it.
> 
> It is just something that is desirable. Look again at the C version: it
> looks off. (At least, you'd use a shorter loop index!)

There's a lot I'd like to have that I don't find in the "C" language.

If I choose to use (or have to use) "C" I use the options I have to best
solve my tasks.

> [...]
> 
>> If you don't like C-style for loop, they absolutely should not
>> exist in a language for which you are, if I understand correctly,
>> the sole implementer and the sole user.
> 
> But I hear so much about how wonderful it is, how multi-purpose, how
> indispensible, how superior to an ordinary 'for' (admittedly from people
> who don't have a choice) that I didn't want to miss out!

No one said that. - You should stop your regular misrepresentations and
also your misinterpretations! - STOP IT, stupid!

Janis