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

On 20.04.2025 13:43, bart wrote:

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

On 19.04.2025 15:05, bart wrote:

 
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.

I haven't said this "is fine". It wasn't at all the topic here.

(Why do you repeatedly show us your frustration about the "C"
language in every post and complain about completely *unrelated*
things to what was said.)

 
Show me a for-loop that cannot be expressed with existing features. Many
are likely to be clearer!

(There have been sufficient examples posted.)

The point is that if you have programming elements that are
related to a loop construct (initialization, exit condition,
update for next iteration) it makes sense to keep them together.
It makes not much sense to spread them across a multi-line block
of statements. - If you haven't ever experienced that, and still
cannot see and understand that if explained to you, then I can't
help you.[*]

[*] Maybe you should visit some University courses. Despite your
long programming history you really seem to miss some elementary
basic programming experiences. Or are you mentally so bound to
primitive loops and your brain so inflexible that nothing helps.

 
I don't know why people think that cramming as much code as possible
into for(...) is a good style of coding.

But that's not what programmers should do. Why do you again make
up things. - The point is to keep things together that belong
together.

Either into one over-long line,
or spilling over multiple lines; both should fail a code review.

(I doubt you've ever been engaged in professional code reviews.)

[...]
 

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.

Why do you think so.

I merely noted that if you, as the language designer, let yourself
get triggered by feature wishes (whether they fit in your language
design or not) that this is not what I'd consider to be sensible.
(Unless you have no "design principles" and just featurities as a
trigger for evolution of your language.) - Anyway, I don't care.

Janis

[...]