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

On 20/04/2025 11:18, Janis Papanagnou wrote:

On 19.04.2025 15:05, bart wrote:

On 19/04/2025 12:32, Janis Papanagnou wrote:

On 19.04.2025 12:26, bart wrote:

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

On 19.04.2025 00:27, bart wrote:

>

>

I'm doing hard to imagine a yet more
primitive one. All other loops pointed out that far (Algol 68,
Simula, "C") allow more complex (less primitive) loop constructs.

>
C, really?

 You have already seen many examples of loops that can't be written
with those heavily restricted Pascal/BASIC/Fortran-like loops.
 

>
I don't understand why you're happy using a crippled looping mechanism,
that is a PITA to use for the majority of iterating loops, just so you
have that flexibility for the whacky loops that are in the minority,
most of which can be trivially expressed with 'while'.

 Because with it I can formulate everything I regularly need in "C"
(as opposed to those primitive and restricted, specialized loops).
 Think about it; what could the alternatives be that the "C" designers
have chosen...
* Provide just a very restricted Pascal like loop? - Then you'd have
all the now common more diverse loops made impossible and require to
spread the loop logic across many primitive language constructs.

Good! If that happens then it's halfway there. At present you see 'for' but have no idea what was in the mind of the programmer until you've deconstructed the header.
(They could have simply called it 'while'; at least people will know what to expect. With 'for' then being available for a more streamlined, compiled-checked loop.)

* Provide two or there forms of 'for' loops to suit your demands? -
That would be a possibility, but language designers often don't want
to overload their language,

But overloading in the form of 30-40 integer types to represent the 8 types i8-i64 and u8-u64, plus the 16 different combinations of writing 'unsigned long long int', and so on, is fine. As are the dozens (hundreds?) of macros in stdint.h/inttypes.h.
 >and especially not invent things that can
 > already be expressed easily with the existing features.
Show me a for-loop that cannot be expressed with existing features. Many are likely to be clearer!
I don't know why people think that cramming as much code as possible into for(...) is a good style of coding. Either into one over-long line, or spilling over multiple lines; both should fail a code review.
Actually here's a example from sqlite3.c:
     for(p=sqliteHashFirst(&pSchema->trigHash); p; p=sqliteHashNext(p)){
         sqlite3DeleteTrigger(db, (Trigger*)sqliteHashData(p));
     }
And this is how you might be forced to write it instead:
     p=sqliteHashFirst(&pSchema->trigHash);
     while (p) {
         sqlite3DeleteTrigger(db, (Trigger*)sqliteHashData(p));
         p=sqliteHashNext(p);
     }
Yes, it's spread over two more lines, but so what? It's much clearer: the initialisation is done once and then it's out of the way. Setting p to the next value is now physically written after the body.
The execution path is simpler, as you will see if you were to draw a line that traces that path.
I mean, I'm surprised the authors here didn't go one step further and put the body inside the loop header too:
     for(p=sqliteHashFirst(&pSchema->trigHash); p; sqlite3DeleteTrigger(db, (Trigger*)sqliteHashData(p)), p=sqliteHashNext(p));
At least, the execution path simplifies! But little else.

I'll tell you a secret: a few years ago, I also added a C-style 'for'
statement to my language. So it had two kinds of 'for' that looked like
this:
>
     for i in a..b do           # also for i[:=a] to b do
>
     cfor A, B, C do            # A B C are arbitrary expressions
>
This was because I'd got fed up with people telling me all these
wonderful things that C's for could do, that I couldn't. So now I could
do the same!

 The feature sets in languages should (IMO) follow a design principle.
It may make sense in one language or not in another language. I don't
know "your language" so I cannot suggest you anything. All I can say
is that such featuritis is, as "design principle", not something that
I'd say you've done right as a basic design approach of your language.
(But as often said; I don't care about "your language" and what you
do in your personal environment.)

So, you don't like the idea of having multiple simple features, each with a well defined job that a compiler can check.
But you like idea of one vaguely defined, open-ended feature that a compiler cannot check, as it doesn't know your intentions, and a reader also has to disentangle.

Most of the discussion with you is mostly "psychological".

It works both ways.