On Mon, 14 Apr 2025 14:18:39 +0200
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:

(While there's some "C" stuff in here it contains a lot of non-"C"
samples for comparison. So [OT]-sensible folks may want to skip this
post.)

On 14.04.2025 12:16, bart wrote:

On 14/04/2025 05:23, Janis Papanagnou wrote:

On 13.04.2025 18:39, bart wrote:

[...]

for(let i = 1; i <= 36; i++) {

Is it that hard to provide a proper for-loop where you don't have
to spell out every single detail?

You mean like in Algol 68 or maybe Simula? (Both are interesting.)

I mean like pretty much every language that hasn't copied C's
for-loop syntax. For example Lua:

for i = a, b # iterate over a..b inclusive
s1
s2
...
end

Obviously there are many and there were many programming languages
that have other and better loop syntaxes than Fortran or Lua (if
above code is all that it provides).

Modern Fortran do construct does not lack in features.
There are languages that match it, but it's hard to see how one can
improve on it without impacting one or another usability aspects.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

(While there's some "C" stuff in here it contains a lot of non-"C"
samples for comparison. So [OT]-sensible folks may want to skip this
post.)

On 14.04.2025 12:16, bart wrote:

On 14/04/2025 05:23, Janis Papanagnou wrote:

On 13.04.2025 18:39, bart wrote:

[...]

for(let i = 1; i <= 36; i++) {

Is it that hard to provide a proper for-loop where you don't have to
spell out every single detail?

You mean like in Algol 68 or maybe Simula? (Both are interesting.)

I mean like pretty much every language that hasn't copied C's for-loop syntax. For example Lua:

for i = a, b # iterate over a..b inclusive
s1
s2
...
end

Obviously there are many and there were many programming languages
that have other and better loop syntaxes than Fortran or Lua (if
above code is all that it provides).

Fortran managed it in the 1950s!

I obviously don't recall FORTRAN good enough to have memorized any
"good" feature. But as (mostly?) an anachronism it anyway doesn't
matter any more (to me).

Fortran's loops looked like this:

do 100 i = a, b
s1
s2
...
100 continue

Okay, I see what you want; just two values (from, to).

This Fortran stuff looks really sick (for my taste)! - The "do 100"
sounds like iterating 100 times, line numbers, 'continue' keyword,
and a list a,b meaning iteration over a range. - Can it be worse?
(Later Fortran versions allow a slightly better syntax, but it's
basically the same anachronistic crude syntax.)

In _minimalistic_ languages I'd prefer, for example, a style like
in Pascal (or in similar languages)

for i := a to b do
statement_block;

It's simple, and a clean formalism.

The C equivalant is this:

for (i = a; i <= b; ++i)
stmt

Differences:

* Fortran has an official loop index variable 'i'.

You are saying that you could not use 'j' ? (This is certainly
different from my memories.) - Anyway, having dedicated variables
for integer types is sick in itself, also if used without loop.

C doesn't; a loop can look like this:

for (x=0; y=1; z=2)

I don't need to tell you that in "C" you can use arbitrary increments/decrements, not just 1, and arbitrary conditions,
and more than one initializer and more increment/decrement
statements, and also omit unnecessary parts.

If all you want is a "+1" increment you can do that in the loop
body where i is used, and initialize it at the declaration point

int i = a;
for (; i <= b ; ) f(i++)

which of course would be written with a 'while'

int i = a;
while (i <= b) f(i++)

The "C" syntax has actually a flexibility that is very valuable.
(Even though I dislike its syntax, but that is a minor point in
this context).

* C needs you to provide the exact comparison op

* C needs you to write the index 'i' three times (with no compiler check
that they're all identical!)

They don't need to be identical, because you can write many more
types of loops than simple counted loops. - This is actually an
advantage; it allows a lot more sensible loop code patterns than
those other primitive loops! - I'm astonished that your code
pattern repertoire is so limited. (Or that you are arguing again
just to contribute anything, however stupid that is.)

* C needs you to specify how to increment the loop index

Of course; another advantage! (And this is common in many
programming languages, older and newer ones.)

* Fortran allows an arbitrary number of statements in the loop body.
C allows only one; multiple statements require a compound statement.

Jesus! - At times I see you as a sensible communication partner,
but in this sub-thread I've no hope. - I'll finish this post and
stop responding to such stupid posts of yours...

[...]

Algol68 also ignores white space, at least within identifiers. That
would have caused clashes with reserved words, so that 'stropping' had
to be employed, resulting in ugly and fiddly-to-type source code.

(Huh? You have issues with keywords in caps? Aren't you used to
that from typically capitalized CPP entities? - But okay. You
have your own languages where you can ignore other people and
implement your personal preferences.)

Of course, in printed material, reserved words simply used bold type,
and it looked gorgeous. The reality on a computer was rather different.

There were various stropping methods used in the past, some
better some worse. The Genie compiler-interpreter uses all caps
and it looks great; makes the keywords stand out and makes the
code structure very clear and perfectly legible! (YMMV.)

And you have a powerful, yet minimalistic syntax; you "pay"
only for what you need and can express anything. Examples...

# infinite loop
DO s1; s2 OD

# loops n times (no variable necessary)
TO n DO s1; s2 OD

# infinite loop with counted index available
FOR i DO s1; s2(i) OD

# loop n times with variable value available
FOR i TO n DO s1; s2(i) OD

... and so on until...

# full arithmetic loop (start, increment, end)
FOR i FROM k BY 3 TO m DO s1; s2(i) OD

# full arithmetic loop with condition
FOR i FROM k BY 3 TO m WHILE cond(i) DO s1; s2 OD

# only condition (no arithmetic)
WHILE cond DO s1; s2 OD

# only condition (with preparing statements)
WHILE s1; s2; cond DO s1; s2 OD

What you can see here are a couple of advantages with
this sort of loop;

* one formal construct (not many variants) to express
all the common loop controls

* better readability (because of stropping!); an easy
differentiation of syntax structure and user defined
entities (variables, conditions, functions, ...)

* all loop-parts (but DO and OD) optional; no typing
overhead, clear constructs, sensible defaults for
omitted parts

* implicit bracketing (no extra braces nor additional
keywords necessary) with short keywords DO OD

* loop variables need no declaration

* loop variable scope is just the loop

The specific Genie compiler-interpreter supports also
a (non-standard) UNTIL part. (Just for completeness.)


The Simula loop, while not as rich as Algol 68's, has
also some distinct specifics; just a short example

FOR z := 2, 3, 5, 7, 11, 13, 17, 19,
21 STEP 2 UNTIL 99,
z+1 WHILE p(z) DO ...

where value lists, counted parts, conditional parts can
be taken and interspersed as necessary (also multiple
times) or just be omitted.

It's also noteworthy that Simula's logic is applicable
also for floating point variables without the danger
of accumulated rounding/truncation issues.


And you think Fortran's loop is a good paragon? *sigh*

Janis

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 14/04/2025 13:18, Janis Papanagnou wrote:

(While there's some "C" stuff in here it contains a lot of non-"C"
samples for comparison. So [OT]-sensible folks may want to skip this
post.)

Fortran's loops looked like this:

do 100 i = a, b
s1
s2
...
100 continue

Okay, I see what you want; just two values (from, to).

This Fortran stuff looks really sick (for my taste)! - The "do 100"
sounds like iterating 100 times, line numbers, 'continue' keyword,
and a list a,b meaning iteration over a range. - Can it be worse?
(Later Fortran versions allow a slightly better syntax, but it's
basically the same anachronistic crude syntax.)

In _minimalistic_ languages I'd prefer, for example, a style like
in Pascal (or in similar languages)

for i := a to b do
statement_block;

I'm not saying there's anything wrong with it. The point was that an A
to B loop existed in the 1950s; C came out in the 1970s!

* Fortran has an official loop index variable 'i'.

You are saying that you could not use 'j' ?

No, it's just 'i' in this example.

which of course would be written with a 'while'

int i = a;
while (i <= b) f(i++)

That would be a poor use of 'while'. And bizarre, to use 'while' for
iteration, but 'for' for loops that are best written as while!

The "C" syntax has actually a flexibility that is very valuable.

The flexibility is the problem, because you have to specify the loop in
such excruciating detail. It is easy to make a mistake which results in
still legal code. And you now have to analyse each loop to see what kind
of loop it is:

Is it simple iteration? Does it count up or down? Are the limits
exclusive or inclusive? Is it something better off as a while-loop? Does
it do multiple things at the same time?

Is there a variable that can be considered to be 'the' loop index?
(Since there can be multiple such variables; even one variable may not necessarily be an 'index', it could be a pointer.)

Suppose you see 'i <= N' as the condition; is that '<=' intentional, or
is it a typo for '<'? It's impossible to tell.

You can also say that a combination of labels, gotos and 'if' is even
more flexible! But C is supposed to be a HLL.

(Even though I dislike its syntax, but that is a minor point in
this context).

* C needs you to provide the exact comparison op

* C needs you to write the index 'i' three times (with no compiler check
that they're all identical!)

They don't need to be identical, because you can write many more
types of loops than simple counted loops. - This is actually an
advantage;

This is the kind of error I was making all the time (writing the first
line, copying it, but forgetting to convert all the variables):

for(i=0; i < M; ++i)
for(j=0; j < N; ++i)

Here, it is not an advantage. I once asked David Brown how many of his for-loops were simple iteration; I think he said 98.5%.

In my case it would be nearer 100%. It's amazing, with the amount of lower-level coding I do, how little I need to use the flexibility of C's
'for'.

Anything unusual can generally be achieved with minor workarounds.

However with linked-list traversal, that's an example that people gave
of how flexible for-loops can be:

for (p = head; p; p = p->next)

I suggested that could have been better done with an extension to
'while'. I made a proof-of-concept in my language:

p := head
while p, p:=p.next do

This feature I've kept.

it allows a lot more sensible loop code patterns than>
those other primitive loops! - I'm astonished that your code
pattern repertoire is so limited. (Or that you are arguing again
just to contribute anything, however stupid that is.)

It sounds like you're being insulting again just to keep your hand in.
Why is it some people just cannot resist getting personal?

* C needs you to specify how to increment the loop index

Of course; another advantage! (And this is common in many
programming languages, older and newer ones.)

You need to tell the computer how to count? OK!

* Fortran allows an arbitrary number of statements in the loop body.
C allows only one; multiple statements require a compound statement.

Jesus! - At times I see you as a sensible communication partner,
but in this sub-thread I've no hope. - I'll finish this post and
stop responding to such stupid posts of yours...

I don't understand; what exactly is the problem here that you see as nonsensical?

In C you have do this:

for(...)
stmt1;

Then you decide to add a new statement, but this doesn't work:

for(...)
stmt1;
stmt2;

(And has caused lots of errors.) You have to refactor into:

for(...) {
stmt1;
stmt2;
}

Then you decide you don't need stmt2 anymore, and may need to refactor
back. Or maybe you want to temporarily comment out stmt1:

for(...)
// stmt1;

But now you will be repeating whatever statement follows iself. It's a
dance.

If I understand you, you think it is idiotic for me to bring up what you clearly perceive as a non-problem?

Even though it is one that also existed in Algol60 and Pascal, and was
solved by Algol68, and now is common in many languages that don't use
braces. (Braces are the equivalent of BEGIN-END.)

[...]

Algol68 also ignores white space, at least within identifiers. That
would have caused clashes with reserved words, so that 'stropping' had
to be employed, resulting in ugly and fiddly-to-type source code.

(Huh? You have issues with keywords in caps?

Yes I have issues with *constantly* switch from lower case all-caps. It
is tedious, error prone and the result is ugly code.

That doesn't bother you? Then you have remarkably low tolerance. But
again, notice that most languages these days do not distinguish reserved
words like that.

There were various stropping methods used in the past, some
better some worse. The Genie compiler-interpreter uses all caps
and it looks great; makes the keywords stand out and makes the
code structure very clear and perfectly legible! (YMMV.)

And you have a powerful, yet minimalistic syntax; you "pay"
only for what you need and can express anything. Examples...

# infinite loop
DO s1; s2 OD

# loops n times (no variable necessary)
TO n DO s1; s2 OD

# infinite loop with counted index available
FOR i DO s1; s2(i) OD

# loop n times with variable value available
FOR i TO n DO s1; s2(i) OD

... and so on until...

# full arithmetic loop (start, increment, end)
FOR i FROM k BY 3 TO m DO s1; s2(i) OD

# full arithmetic loop with condition
FOR i FROM k BY 3 TO m WHILE cond(i) DO s1; s2 OD

# only condition (no arithmetic)
WHILE cond DO s1; s2 OD

# only condition (with preparing statements)
WHILE s1; s2; cond DO s1; s2 OD

(Note: Algol68 comments need a trailing # too.)

I have all those in my syntax, in fact the above would be legal sytax in
my langage (since it is case-insensitive), apart from minor details:

* I use := instead of FROM

* I use TO/BY rather than BY/TO

* I don't have embedded WHILE, instead I have embedded WHEN, which
affects only that iteration. (WHILE will stop the loop when false. Note
that Algol68 did not have 'break'; it has to use 'goto'.)

Also, DO, TO and WHILE are independent features in my language, but
that's an internal detail.

I also have some extras that are not in Algol68, such as being able to
iterate over values (of a list etc), or an optional ELSE clause.

However, I'm not sure why we're talking about Algol68: my complaint was
about why some languages chose to copy C's crude for-loop syntax, but it
it was considered primitive even in 1972.

What you can see here are a couple of advantages with
this sort of loop;

* one formal construct (not many variants) to express
all the common loop controls

As I said, I have the same features, but it is multiple constructs. So
having 'one construct' is just a gimmick.

* better readability (because of stropping!); an easy
differentiation of syntax structure and user defined
entities (variables, conditions, functions, ...)

That's rubbish too. I can also write:

FOR i := a TO b DO

if I want (but I don't as it's just a pain). It works because it is case-insensitive.

* all loop-parts (but DO and OD) optional; no typing
overhead, clear constructs, sensible defaults for
omitted parts

I have sensible defaults too! I also don't have annoying rules about semicolons, or problems with empty bodies:

DO SKIP OD

I don't need 'SKIP'.

DO
s1;
s2;
s3
OD

Notice s3 is special-cased, as it has no semicolon. This leads to fun
and games when inserting, deleting, moving statements, or even
temporarily commenting lines in or out. At least C gets this right! (Mostly)

The Simula loop, while not as rich as Algol 68's, has
also some distinct specifics; just a short example

FOR z := 2, 3, 5, 7, 11, 13, 17, 19,
21 STEP 2 UNTIL 99,
z+1 WHILE p(z) DO ...

What is it demonstrating? Since it seems to be merely this:

for z in X while p(z) DO

where X is any expression including such a constructor. I can do some of
this stuff, but in my next language up. It is higher level than what
we're discussing, and not even much about loops.

And you think Fortran's loop is a good paragon? *sigh*

It seems we could have kept this short.

I said that Fortran's original DO-loop was more advanced than C's for-loop.

You are saying that because there exist languages with more
sophisticated loops, that that somehow excuses C's poor effort?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 14.04.2025 23:44, Keith Thompson wrote:

Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:

(While there's some "C" stuff in here it contains a lot of non-"C"
samples for comparison. So [OT]-sensible folks may want to skip this
post.)
On 14.04.2025 12:16, bart wrote:

[...]

Fortran's loops looked like this:

do 100 i = a, b
s1
s2
...
100 continue

Okay, I see what you want; just two values (from, to).

This Fortran stuff looks really sick (for my taste)! - The "do 100"
sounds like iterating 100 times, line numbers, 'continue' keyword,
and a list a,b meaning iteration over a range. - Can it be worse?
(Later Fortran versions allow a slightly better syntax, but it's
basically the same anachronistic crude syntax.)

To any programmer familiar with that version of Fortran, the 100 doesn't
look like iterating 100 times. It looks like a label, and it's
reasonably consistent with other constructs that refer to labels. The
syntax isn't great, but don't judge an unfamiliar language syntax by one example.

Not sure what you mean by "unfamiliar"; back these days it was quite
commonly known in the IT scene. Myself I programmed in Fortran during
the 1980's; that was enough to identify all its crudeness[*].

The Fortran language is not different than any other language in that
respect that you have to learn it, understand it, accept it, and then
use it. If you're judging any language from a design perspective then
it's good to overcome arguing just within the language but take into considerations what other languages did and, with a step back, what
constructs are exposed to the one learning the syntax.

The "do 100 i = a, b" is from design perspective in principle not
different to, for example, the crude declaration details of "C". It's
not something that we would need to complain about given that Fortran
is very old. But advocating it is far off, especially in the light of
the back then next generation languages; Algol 60, Pascal, and so on,
including even that (old, crude) BASIC, which all offer more sensible
loop syntaxes to their programmers.

We don't need to judge Fortran by contemporary languages, it suffices
to compare it with the language generation following Fortran since the
1960's. (Or just use common sense.)

Janis

[*] But gladly not enough to not forget after four decades all the
really gory details.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Mon, 14 Apr 2025 14:18:39 +0200, Janis Papanagnou wrote:

(While there's some "C" stuff in here it contains a lot of non-"C"
samples for comparison. So [OT]-sensible folks may want to skip this
post.)

On 14.04.2025 12:16, bart wrote:

On 14/04/2025 05:23, Janis Papanagnou wrote:

On 13.04.2025 18:39, bart wrote:

[...]

for(let i = 1; i <= 36; i++) {

C for loop is great, but all can be workarounded with goto label

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 15.04.2025 06:57, Rosario19 wrote:

On 13.04.2025 18:39, bart wrote:

[...]

for(let i = 1; i <= 36; i++) {

C for loop is great, but all can be workarounded with goto label

Sure. Or all done with Turing machines. - But why would one want to.

Maybe a note aside on your comment; I haven't read many specification
documents of contemporary language lately, but many of those old specs
often described the semantics of high-level constructs (like loops) by
an equivalent 'goto' based code pattern.

Janis

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 14.04.2025 17:22, bart wrote:

On 14/04/2025 13:18, Janis Papanagnou wrote:

(While there's some "C" stuff in here it contains a lot of non-"C"
samples for comparison. So [OT]-sensible folks may want to skip this
post.)

[...]

I'm not saying there's anything wrong with it. The point was that an A
to B loop existed in the 1950s; C came out in the 1970s!

[...]

[...]

which of course would be written with a 'while'

int i = a;
while (i <= b) f(i++)

That would be a poor use of 'while'.

Not the least.

And bizarre, to use 'while' for
iteration, but 'for' for loops that are best written as while!

I was merely trying to provide some options to address your dislike.

The "C" syntax has actually a flexibility that is very valuable.

The flexibility is the problem, because you have to specify the loop in
such excruciating detail. It is easy to make a mistake which results in
still legal code. And you now have to analyse each loop to see what kind
of loop it is:

Well, our opinions obviously differ. I just give you two examples
(and there's many variants of these) of not uncommon 'for' usages...

for (c=0; bitstr; c++)
bitstr &= bitstr-1;

for (r=1; r<=0x80; r<<=1)
...

and someone already posted another iteration type on linked lists

for (node = list; node; node = node->next)

The point here is the observation that there are loops that deviate
from simple counted loops (and that are commonly used) and that they
all comprise the same principal structure; initialization, condition
test, change of loop-variables. The "C" loop syntax reflects that in
its typical low-level syntax form. (I already said that personally I
don't like "C"'s syntax, but I do like its flexibility.)

[...]

Suppose you see 'i <= N' as the condition; is that '<=' intentional, or
is it a typo for '<'? It's impossible to tell.

(This is nonsense.)

You can also say that a combination of labels, gotos and 'if' is even
more flexible! But C is supposed to be a HLL.

Actually, "C" is (IMO) not as high-level as some other languages are.
I always considered it (snippy) as a excellent "assembler". So if I
judge "C"'s constructs I do so on the abstraction level the designers
have chosen. (Or at least I try to do that.)

(It's nonsense to make up an "argument" for 'goto'.)

[...]

They don't need to be identical, because you can write many more
types of loops than simple counted loops. - This is actually an
advantage;

This is the kind of error I was making all the time (writing the first
line, copying it, but forgetting to convert all the variables):

for(i=0; i < M; ++i)
for(j=0; j < N; ++i)

That first of all means that you are obviously a sloppy programmer.

Especially if you are doing that "all the time" it's something you
should work on. (And I don't mean, by writing yet another personal
programming language that suits you better.)

(There's something I've heard about in the 1990's, "PSP", "Personal
Software Process"[*], that might help you increase your success rate
by reducing common errors you make.)

[*] https://en.wikipedia.org/wiki/Personal_software_process

Here, it is not an advantage. I once asked David Brown how many of his for-loops were simple iteration; I think he said 98.5%.

This number, I think, may be close to reality. - I want to remind
that N. Wirth gave such informal statistics as rationale for Pascal
only supporting for-loops with increment and decrement values of 1.

But given the flexibility of "C"'s syntax that statistics certainly
has changed; with "C" you can formulate sensible 'for' loops that
were just not possible [within the 'for'-syntax] before. (I gave
[just a few] example above; there's yet more.) Now that you can
formulate such loops their number increased as far as I observe.

In my case it would be nearer 100%. It's amazing, with the amount of lower-level coding I do, how little I need to use the flexibility of C's 'for'.

I'm not too astonished; programming is also based on many personal
factors.

Anything unusual can generally be achieved with minor workarounds.

However with linked-list traversal, that's an example that people gave
of how flexible for-loops can be:

for (p = head; p; p = p->next)

I suggested that could have been better done with an extension to
'while'. I made a proof-of-concept in my language:

p := head
while p, p:=p.next do

This feature I've kept.

Now that is strange. - Before[*] you argued on a 'while' example:

"That would be a poor use of 'while'. And bizarre, to use
'while' for iteration, but 'for' for loops that are best
written as while!"

Your mindset on that seems to not yet have reached a stable state.

But back to the topic; why do you think that introducing yet another
new syntax would be sensible or even more useful than just using an
already existing (and fitting) one; because you don't like it that
way?

[*] I had snipped it in this post because it appeared to me so
nonsensical, but if I knew that you support that... - Anyway.

it allows a lot more sensible loop code patterns than>
those other primitive loops! - I'm astonished that your code
pattern repertoire is so limited. (Or that you are arguing again
just to contribute anything, however stupid that is.)

It sounds like you're being insulting again just to keep your hand in.
Why is it some people just cannot resist getting personal?

There's a few properties that you have problems with that lie not
within the language but are inherent part of your personality. -
You clearly exposed two of them; above your problem of handling
your copy/paste programming errors ("PSP") and here that you are
restricted in your self-imposed cage of not detecting (and also
not understanding, if told) that there's many more that you don't
perceive and that it's used to advantage.

* C needs you to specify how to increment the loop index

Of course; another advantage! (And this is common in many
programming languages, older and newer ones.)

You need to tell the computer how to count? OK!

Yes. - Either i++ or i+=2 or z*=10 or r<<=4 or ...

You say OK but you don't see the obvious applications, do you?
Meanwhile?

* Fortran allows an arbitrary number of statements in the loop body.
C allows only one; multiple statements require a compound statement.

Jesus! - At times I see you as a sensible communication partner,
but in this sub-thread I've no hope. - I'll finish this post and
stop responding to such stupid posts of yours...

I don't understand; what exactly is the problem here [...]

There's languages (like Algol 68, Eiffel, Unix Shell, etc.)
where you have "closed" control constructs (if-fi, do-done,
case-esac) which make it unnecessary to introduce blocks or
compound statements in their context. In other languages
(Pascal, Simula, "C", etc.) you don't have that and if you
want to have multiple statements in a control structure you
naturally need to syntactically comprise them.

That doesn't make the crude and limited Fortran 'for' loop
any better only because it has a "100 continue" or "end do".

In C you have do this:

[ snip bart's known problems with compound statement blocks ]

(I suggest, here as well, to make yourself familiar with the
above mentioned "PSP" methods if you have difficulties with
program evolution and compound statements.)

If I understand you, you think it is idiotic for me to bring up what you clearly perceive as a non-problem?

(I see you have a problem that only you can fix.)

Even though it is one that also existed in Algol60 and Pascal, and was
solved by Algol68, and now is common in many languages that don't use
braces. (Braces are the equivalent of BEGIN-END.)

Having "closed" control constructs (i.e. making explicit braces
unnecessary) is IMO a Very Good Thing; and personally I prefer
languages that support such syntaxes. "C" is not such a language.

Having end-tags doesn't make Fortran a good language or its 'do'
loop a good syntax.

(Huh? You have issues with keywords in caps?

Yes I have issues with *constantly* switch from lower case all-caps. It
is tedious, error prone and the result is ugly code.

Okay.

That doesn't bother you? [...]

I'm no typist, I have no typist's education, but with my decades
practice in programming I type sufficiently fast and have indeed
no problem to occasionally put my small finger on the Shift key
as professional typists do. - No that doesn't bother me.

(Things that bother me w.r.t. typing are that the braces that are
typical of "C" and used there in masses are on my non-US keyboard
quite difficult to reach.)

But
again, notice that most languages these days do not distinguish reserved words like that.

Yes. And I'm fine with that. Especially since I'm using editors
with syntax highlighting and nowadays don't print source code
in black and white on paper any more. For plain text posts it's
still an advantage, though, to have the keywords stand out. And
despite the highlighting in my editor it also adds to readability
when writing and reading programs.

There were various stropping methods used in the past, some
better some worse. The Genie compiler-interpreter uses all caps
and it looks great; makes the keywords stand out and makes the
code structure very clear and perfectly legible! (YMMV.)

And you have a powerful, yet minimalistic syntax; you "pay"
only for what you need and can express anything. Examples...

[ snip Algol 68 examples ]

(Note: Algol68 comments need a trailing # too.)

Yes, I know. I added that '#' for posting only. (Despite '#' is
[pairwise] usable in the Genie context I'm nonetheless using
the classical and portable CO ... CO in my programs instead.)

[ snip some bart language specific features ]

* I don't have embedded WHILE, instead I have embedded WHEN, which
affects only that iteration. (WHILE will stop the loop when false. Note
that Algol68 did not have 'break'; it has to use 'goto'.)

Yes, Algol 68 (as so many languages back these days) has 'goto'
available, and used with labels (as opposed to line numbers).

(You don't need 'break' or 'goto' to leave loops, especially if
the language supports [also as part of a 'for' loop] 'while'.)

But what are you trying to say here?

[ snip more bart language specific features ]

However, I'm not sure why we're talking about Algol68:

(Oh, right, and obviously also about your language/preferences.)

my complaint was
about why some languages chose to copy C's crude for-loop syntax,

You mixed into the discussion _your_ compound statement issue
[that Algol 68 addresses]. You said your language addresses some
of the issues you have with "C"'s syntax, where you did not a
job as good as Algol 68 did. You could not see, less appreciate
the flexibility of "C"'s 'for' loop syntax design decision.

but it it was considered primitive even in 1972.

The whole "C" language is "primitive" (in some respects) if
compared to other HLLs.

[...]

* all loop-parts (but DO and OD) optional; no typing
overhead, clear constructs, sensible defaults for
omitted parts

I have sensible defaults too! I also don't have annoying rules about semicolons,

(Yes, I know that you have noticeable problems where others don't
care much. You repeatedly told and reminded us about that. Okay.)

or problems with empty bodies:

DO SKIP OD

If there'd be an 'empty statement' possible to have in Algol 68
(so that I could omit the 'SKIP' in your example) I'd likely have
nonetheless added a comment to indicate the deliberate absence of
a statement. (I use such defensive programming patterns with comments
also in other languages.) YMMV, but I think it's useful if people
work together in projects, but also if one is programming just for
own fun.

Where you think a terse DO OD is best others might prefer to see
it documented DO # nothing to do # OD and are delighted if that
"comment" is even standardized by a clear 'NOP' as in DO SKIP OD .

[...]

The Simula loop, while not as rich as Algol 68's, has
also some distinct specifics; just a short example

FOR z := 2, 3, 5, 7, 11, 13, 17, 19,
21 STEP 2 UNTIL 99,
z+1 WHILE p(z) DO ...

What is it demonstrating?

That there are a couple _different_ ways that language designers
can address loop semantics and supported loop features. All the
three languages have differing approaches, and all with sensible
rationales.

Since it seems to be merely this:

for z in X while p(z) DO

No. As opposed to Algol 68 the Simula 'while' condition is bound
[in the example above] to the "z+1" part of the 'for' expression.

[...]

And you think Fortran's loop is a good paragon? *sigh*

It seems we could have kept this short.

I said that Fortran's original DO-loop was more advanced than C's for-loop.

You are saying that because there exist languages with more
sophisticated loops, that that somehow excuses C's poor effort?

No.

I was saying that there are different approaches in different
languages, and that there are good reasons why these languages
(Algol 68, Simula, Pascal, "C") have defined it in their way;
you can do useful things in very flexible (and clear) ways.
(And that Fortran is IMO not amongst those languages. - YMMV.)

(I also hinted about some other things, your issues and "your
language", how you "solved" those "issues", that are not worth
expanding on.)

Janis

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 15/04/2025 05:57, Rosario19 wrote:

On Mon, 14 Apr 2025 14:18:39 +0200, Janis Papanagnou wrote:

(While there's some "C" stuff in here it contains a lot of non-"C"
samples for comparison. So [OT]-sensible folks may want to skip this
post.)

On 14.04.2025 12:16, bart wrote:

On 14/04/2025 05:23, Janis Papanagnou wrote:

On 13.04.2025 18:39, bart wrote:

[...]

for(let i = 1; i <= 36; i++) {

C for loop is great, but all can be workarounded with goto label

For this specific example (ignore 'let' for C), please explain why it is
better than, say:

FOR(i,1,36) {

This is 99% of my for-loops. Is it the same reasoning why I have to
write 'break' in 99% of my switch-blocks?

There's something about this group which celebrates these annoying
language characteristics which are only useful or meaningful in a tiny
minority of cases: see how wonderful it is for 1% of the time?

That must surely justify them being both a PITA and dangerously error
prone in the vast majority of cases!

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 15/04/2025 08:17, Janis Papanagnou wrote:

On 14.04.2025 17:22, bart wrote:

On 14/04/2025 13:18, Janis Papanagnou wrote:

(While there's some "C" stuff in here it contains a lot of non-"C"
samples for comparison. So [OT]-sensible folks may want to skip this
post.)

[...]

I'm not saying there's anything wrong with it. The point was that an A
to B loop existed in the 1950s; C came out in the 1970s!

[...]

[...]

which of course would be written with a 'while'

int i = a;
while (i <= b) f(i++)

That would be a poor use of 'while'.

Not the least.

And bizarre, to use 'while' for
iteration, but 'for' for loops that are best written as while!

I was merely trying to provide some options to address your dislike.

The "C" syntax has actually a flexibility that is very valuable.

The flexibility is the problem, because you have to specify the loop in
such excruciating detail. It is easy to make a mistake which results in
still legal code. And you now have to analyse each loop to see what kind
of loop it is:

Well, our opinions obviously differ. I just give you two examples
(and there's many variants of these) of not uncommon 'for' usages...

for (c=0; bitstr; c++)
bitstr &= bitstr-1;

I can't grok that.

for (r=1; r<=0x80; r<<=1)
...

and someone already posted another iteration type on linked lists

for (node = list; node; node = node->next)

These two I get, and I can tell you that they're all WHILE loops. To
make make them tidier, I'd have fewer complaints about them if they
instead looked like this:

while (node = list; node; node = node->next)

So, you can optionally add extra elements to a while (x).

It would be necessary to either define whether while(x; y) means while
(; x; y) or while (x; y), or to always require either zero or two
semicolons inside (...).

That could have kept 'for' for how it works in other languages (the ones
that haven't just blindly copied C's version!).

The point here is the observation that there are loops that deviate
from simple counted loops (and that are commonly used) and that they
all comprise the same principal structure; initialization, condition
test, change of loop-variables. The "C" loop syntax reflects that in
its typical low-level syntax form. (I already said that personally I
don't like "C"'s syntax, but I do like its flexibility.)

Let me ask you this: what exactly is the point of the 'while' statement
in C? Since it can always be trivially be written as:

for (;cond;)

It seems to that most use cases (initialise, check exit condition,
change something that affects the letter), would suit 'for' better.

But since 'for' then becomes overloaded, there ought to be a dedicated
feature for simple iteration. So it seems the solution is as a I
suggested above.

[...]

Suppose you see 'i <= N' as the condition; is that '<=' intentional, or
is it a typo for '<'? It's impossible to tell.

(This is nonsense.)

You can't just say that without explanation. WHY it it nonsense? Take this:

for (i=0 i<=N; ++i)

Most such loops iterate over 0..N-1 inclusive, so would need "<". So, in
your opinion, is that <= a typo, or is the intention to iterate over
0..N inclusive (so N+1 iterations)?


(May reply to rest separately.)

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tue, 15 Apr 2025 11:15:06 +0100
bart <bc@freeuk.com> wrote:

On 15/04/2025 05:57, Rosario19 wrote:

On Mon, 14 Apr 2025 14:18:39 +0200, Janis Papanagnou wrote:

(While there's some "C" stuff in here it contains a lot of non-"C"
samples for comparison. So [OT]-sensible folks may want to skip
this post.)

On 14.04.2025 12:16, bart wrote:

On 14/04/2025 05:23, Janis Papanagnou wrote:

On 13.04.2025 18:39, bart wrote:

[...]

for(let i = 1; i <= 36; i++) {

C for loop is great, but all can be workarounded with goto label

For this specific example (ignore 'let' for C), please explain why it
is better than, say:

FOR(i,1,36) {

This is 99% of my for-loops. Is it the same reasoning why I have to
write 'break' in 99% of my switch-blocks?

There's something about this group which celebrates these annoying
language characteristics which are only useful or meaningful in a
tiny minority of cases: see how wonderful it is for 1% of the time?

That must surely justify them being both a PITA and dangerously error
prone in the vast majority of cases!

I regularly use two languages with "proper loops" - Matlab/Octave and
VHDL (Ada-like syntax). When writing loops in these languages, I don't
feel any extra convenience over C. Nor do you suffer from reduced
flexibility relatively to C, except very rarely.
In other words, I don't care.

And it's not because I can become accustomed to anything. E.g. I am
using tcl for a long time. I never stopped hating most of its syntax,
including for loops.

I probably will care (i.e. dislike) language (or C macro) with the
syntax shown in your last example, but less intensely than tcl.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tue, 15 Apr 2025 11:30:24 +0100
bart <bc@freeuk.com> wrote:

Let me ask you this: what exactly is the point of the 'while'
statement in C? Since it can always be trivially be written as:

for (;cond;)

It seems to that most use cases (initialise, check exit condition,
change something that affects the letter), would suit 'for' better.

But since 'for' then becomes overloaded, there ought to be a
dedicated feature for simple iteration. So it seems the solution is
as a I suggested above.

I suspect that 'while' loop is here in C because Dennis Ritchie wanted
'do .. while() ' and thought that if the keyword is here anyway than
why not reuse it?
In the hindsight, probably a mistake.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 15/04/2025 13:34, Michael S wrote:

<snip>

I suspect that 'while' loop is here in C because Dennis Ritchie wanted
'do .. while() ' and thought that if the keyword is here anyway than
why not reuse it?
In the hindsight, probably a mistake.

In hindsight:

$ find . -name \*.c | xargs cat | wc -l
126343
$ find . -name \*.c | xargs grep -w while | wc -l
556
$ find . -name \*.c | xargs grep -w for | wc -l
1258


So although I use for() about twice as much as I use while(), I
still find while a better option one time in three. That's useful
enough to make it worth keeping in the toolbox.

--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 15/04/2025 13:25, Michael S wrote:

On Tue, 15 Apr 2025 11:15:06 +0100
bart <bc@freeuk.com> wrote:

On 15/04/2025 05:57, Rosario19 wrote:

On Mon, 14 Apr 2025 14:18:39 +0200, Janis Papanagnou wrote:

(While there's some "C" stuff in here it contains a lot of non-"C"
samples for comparison. So [OT]-sensible folks may want to skip
this post.)

On 14.04.2025 12:16, bart wrote:

On 14/04/2025 05:23, Janis Papanagnou wrote:

On 13.04.2025 18:39, bart wrote:

[...]

for(let i = 1; i <= 36; i++) {

C for loop is great, but all can be workarounded with goto label

For this specific example (ignore 'let' for C), please explain why it
is better than, say:

FOR(i,1,36) {

This is 99% of my for-loops. Is it the same reasoning why I have to
write 'break' in 99% of my switch-blocks?

There's something about this group which celebrates these annoying
language characteristics which are only useful or meaningful in a
tiny minority of cases: see how wonderful it is for 1% of the time?

That must surely justify them being both a PITA and dangerously error
prone in the vast majority of cases!

I regularly use two languages with "proper loops" - Matlab/Octave and
VHDL (Ada-like syntax). When writing loops in these languages, I don't
feel any extra convenience over C.

I'm not familiar with those, but the first Ada loop example I googled
for was this:

for Variable in 0 .. 9 loop

In C that exact example would be:

for (Variable = 0; Variable < 10; ++Variable) {

or maybe:

for (Variable = 0; Variable <= 9; Variable = Variable + 1) {

So, in the Ada:

* Not having to write the variable 3 times (with C not always being
able to detect if they didn't match)

* Not having to either offset the upper limit, or juggle between <
and <=

* Not having to explicitly provide the code to increment the variable

doesn't have ANY extra convenience?

(You can have a 100MB compiler and you still have to tell it how to
increment a loop index! That is plain crazy.)

And it's not because I can become accustomed to anything. E.g. I am
using tcl for a long time. I never stopped hating most of its syntax, including for loops.

TCL's for loop appears to be inspired by C's:

for {set Variable 0} {$Variable < 10} {incr Variable} {

It's extraordinary how difficult a task it appears to be with some
languages to iterate a variable over a range!

I acknowledge that with the popularity of zero-based languages, which
means usually iterating over 0..N-1 inclusive rather than 1..N, there is
some confusing about denoting the upper limit.

So I invented a new postfix operator which turns an inclusive upper
limit into an exclusive one. It looks like "-1", and works like this:

FOR Variable in 0..N-1

Most C code I write manually is small sequences mainly to do with
compiler testing and benchmarks. 'for'-loops and especially 'printf'
feature heavily.

Those are two features with an unnecessarily elaborate syntax where you
have to dot all the i's and cross all the t's, even for temporary code
that is only needed for a few minutes.

That is incredibly annoying, especially as I am a terrible typist.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2025-04-15, bart <bc@freeuk.com> wrote:

* Not having to write the variable 3 times (with C not always being
able to detect if they didn't match)

This is indeed a source of errors in C nested loops. Say we have
these macros:

FOR (i, 0, N-1)
FOR (j, 0, i)
...

we are less likely to make some copy paste error like

for (i = 0; i < N; i++)
for (j = 0; j < i; i++)
...

Int he past, I've run into bugs in nested loops, along these lines.

In loop-heavy code, making a macro like the FOR above might not
be a bad idea.

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2025-04-15, bart <bc@freeuk.com> wrote:

On 15/04/2025 08:17, Janis Papanagnou wrote:

and someone already posted another iteration type on linked lists

for (node = list; node; node = node->next)

These two I get, and I can tell you that they're all WHILE loops. To
make make them tidier, I'd have fewer complaints about them if they
instead looked like this:

while (node = list; node; node = node->next)

That's mostly bike shedding. It could also have been called:

do (node = list; node; node = node->next)

loop (node = list; node; node = node->next)

Lisp called this kind of general variable stepping loop "do"

(do ((var1 init1 step1)
(var2 init1 step2)
...)
(until-this-is-true also-this ... yield-this-result)
do-this
and-this
...)

Naming things can be hard. The reason that the loop is called for
is that most instance of for have a focus on the specific variable
that is initialized, and the guard condition has to do with it
hitting some specific terminating value.

So, you can optionally add extra elements to a while (x).

It would be necessary to either define whether while(x; y) means while
(; x; y) or while (x; y), or to always require either zero or two
semicolons inside (...).

That could have kept 'for' for how it works in other languages (the ones
that haven't just blindly copied C's version!).

Common Lisp uses "for" to indicate several kinds of variable
stepping clauses inside the loop syntax, some of which are:

[4]> (loop for x in '(a b c)
for y = 1 then (1+ y)
for z = (* y 10)
with w = (* y 10)
collect (list x y z w))
((A 1 10 10) (B 2 20 10) (C 3 30 10))

When loop is used to simulate the classic Lisp do loop,
it's done with the "for var = init then step" clauses.

There is a "for var from N to M" clause, as well as "for var below N"
which goes from 0 to N-1.

Why the C for loop is called "for" is that it is oriented toward
variable stepping. The while part of it is just the termination test.

for (node = list, count = 0;
node;
node = node->next, count++)
...

While loops occur that are not focused on stepping specific variables:

while (!(*status_port & CTS)) { }

while (queue_empty(q))
cond_wait(&condvar, &mutex);

Let me ask you this: what exactly is the point of the 'while' statement
in C?

Since it can always be trivially be written as:

for (;cond;)

That is simply untidy looking.

If C had a preprocessor from the beginning, while could have ben defined as:

#define while(cond) for(;cond;)

There are still some reasons not to do that, and preprocessing
came later.

It seems to that most use cases (initialise, check exit condition,
change something that affects the letter), would suit 'for' better.

The new for can declare a variable. This is important in macros
because the loop header encloses the declaration, such that
it cannot accidentally tear away as a fragment of another
statement:

This macro:

#define step(type, var, from, to) for(type var = from; var <= to; var ++)

cannot be defined using while without issues.

#define step(type, var, from, to) type var = from; while (var <= to; var ++)

Yes; we can make a macro

#define whl(cond) for (;cond;)

But since 'for' then becomes overloaded, there ought to be a dedicated feature for simple iteration.

Once the macro preprocessor was introduced, programmers met their
need for dedicated, simplified iteration constructs that way, albeit imperfectly.

// step n for each node in list

list_for (n, list) { .... }

#define list_for(n, list) for (node n = list; n; n = n->next)

A lot of these kinds of macros have issues of hygiene; we wouldn't
want them in a standard header file. They serve well the specific
codebase they are in, and that's all that can be said for them.

Suppose you see 'i <= N' as the condition; is that '<=' intentional, or
is it a typo for '<'? It's impossible to tell.

(This is nonsense.)

You can't just say that without explanation. WHY it it nonsense? Take this:

for (i=0 i<=N; ++i)

It isn't nonsense. Guard conditions in for loops have historically been a source of off-by-one errors in C programming, which bears acknowledging.

Most such loops iterate over 0..N-1 inclusive, so would need "<". So, in
your opinion, is that <= a typo, or is the intention to iterate over
0..N inclusive (so N+1 iterations)?

Indeed in a "for i from 0 to n + 1" type construct, it is
vanishingly unlikely that n + 1 is a typo.

It may be wrong, but as a finger slip-up that the eyes didn't catch.

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

bart <bc@freeuk.com> writes:

On 15/04/2025 05:57, Rosario19 wrote:

On Mon, 14 Apr 2025 14:18:39 +0200, Janis Papanagnou wrote:

(While there's some "C" stuff in here it contains a lot of non-"C"
samples for comparison. So [OT]-sensible folks may want to skip this
post.)

On 14.04.2025 12:16, bart wrote:

On 14/04/2025 05:23, Janis Papanagnou wrote:

On 13.04.2025 18:39, bart wrote:

[...]

for(let i = 1; i <= 36; i++) {

C for loop is great, but all can be workarounded with goto label

For this specific example (ignore 'let' for C), please explain why it is >better than, say:

FOR(i,1,36) {

Because it can't do this:

for(tp = root; tp != NULL; tp = tp->next)

This is 99% of my for-loops.

Who cares what your for-loops are like?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 15/04/2025 14:33, Kaz Kylheku wrote:

On 2025-04-15, bart <bc@freeuk.com> wrote:

* Not having to write the variable 3 times (with C not always being
able to detect if they didn't match)

This is indeed a source of errors in C nested loops.

According to Janis Papanagnou, it is 100% the programmer's fault. There
is nothing wrong with the language!

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 15/04/2025 08:17, Janis Papanagnou wrote:

On 14.04.2025 17:22, bart wrote:

(It's nonsense to make up an "argument" for 'goto'.)

The fastest bytecode interpreters in C, at present rely on using
'computed goto' (although along with label pointers, an extension).

There are other uses too: C is popular as an intermediate language, and
to that end, 'goto' is essential to express constructs the original
language may have, but don't exist in C.

There are other applications, but I doubt that will cut any ice.
Probably you personally haven't used 'goto' since 1986, and think no one
else needs to use it either.

This is the kind of error I was making all the time (writing the first
line, copying it, but forgetting to convert all the variables):

for(i=0; i < M; ++i)
for(j=0; j < N; ++i)

That first of all means that you are obviously a sloppy programmer.

And that's the kind of remark that shows you haven't a clue about
ergonomic language design. Why deliberately design a feature with so
many extra, undetectable, error opportunities?

Oh, I know: why don't we just put all the blame on the programmer! They
will just have to be extra careful instead on concentrating on more
relevant matters.

A good thing that approach is not used on safety matters in real life.

(There's something I've heard about in the 1990's, "PSP", "Personal
Software Process"[*], that might help you increase your success rate
by reducing common errors you make.)

[*] https://en.wikipedia.org/wiki/Personal_software_process

That's brilliant, thanks. So when I'm finding it incredibly error-prone
to write my applications in 100% assembly, it's nothing at all to do
with the poor choice of language, I'm just incredibly sloppy, and that
web-site will help me!

Here, it is not an advantage. I once asked David Brown how many of his
for-loops were simple iteration; I think he said 98.5%.

This number, I think, may be close to reality. - I want to remind
that N. Wirth gave such informal statistics as rationale for Pascal
only supporting for-loops with increment and decrement values of 1.

I agree with Wirth. Anything unusual can be trivially expressed with
WHILE. Most languages support WHILE, and so can express anything that
C's FOR loop can.

The result is that FOR is a simple, streamlined iteration feature,
instead of a free-for-all which can require readers double-guessing the programmer's intention.

Now that is strange. - Before[*] you argued on a 'while' example:

"That would be a poor use of 'while'. And bizarre, to use
'while' for iteration, but 'for' for loops that are best
written as while!"

Do you understand WHY it was a poor choice? Clearly not. It was poor
choice because you used WHILE to implement a simple iteration of 'i'
over 'a' to b'. That is *exactly* what FOR should be used for.

There two main kinds of iterations, putting aside endless loops, and repeat-N-times with no index:

(1) Where the number of iterations is known in advance, and the
iteration is over a numerical sequence or a set of values

(2) Where the number of iterations is either not known in advance, or
the termination depends on some condition.

Here's my poser: which one of these is typically done by FOR in most
languages, and which is done by WHILE?

I suspect you have got these mixed up. You showed WHILE being used for
(1), and you heavily promote FOR to be used for (2).

Or maybe this everything backwards thinking is just typical of C!

There's a few properties that you have problems with that lie not
within the language but are inherent part of your personality. -
You clearly exposed two of them; above your problem of handling
your copy/paste programming errors ("PSP")

So, in your opinion, that issue I had was 100% my fault, and 0% due to
poor language design?

To reiterate that C example:

for(i=0; i<M; ++i)

I had to duplicate this line and change 4 identifiers within it. In my
syntax, I would duplicate this line:

for i to M do

and change only 2 identifiers. In C there is twice as much scope for the
error, and there is more infrastructure for it to hide behind, but it
still doesn't matter?

Suppose the loop indices are not needed inside the bodies; in my
language I would just write:

to M do
to N do

Here I wouldn't copy and paste, it's easier to just type those 3 tokens!
So there is no opportunity for error.

Do you still say that ergonomic language design plays no part in this AT
ALL, it is always 100% Bart's fault?

* C needs you to specify how to increment the loop index

Of course; another advantage! (And this is common in many
programming languages, older and newer ones.)

You need to tell the computer how to count? OK!

Yes. - Either i++ or i+=2 or z*=10 or r<<=4 or ...

Even for 99.9% of loops where you increment by one? Yikes!

You say OK but you don't see the obvious applications, do you?

It's very simple:

for i := a to b do # automatically increments by 1 ...
for i := a to b by c do # ... unless told otherwise

The default should be to increment by 1. Do you have a problem with that concept? In Ada it's apparently:

for i in a .. b loop

It seems to have figured it out! Even Fortran managed it.

do 100 i = a, b # increment by 1
do 100 i = a, b, c # increment by c

This is a truely fascinating place, where black is white and every
crappy misfeature is an essential must-have!

That doesn't make the crude and limited Fortran 'for' loop
any better only because it has a "100 continue" or "end do".

It is yet another advantage that C doesn't have, and which other
languages have had to introduce.

In C, braces, /and the ability to not use them for one statement/ are
another poor feature which can lead to often undetectable errors.

Just look at the vast number of placement syles that exist. It's all a
huge headache that those languages with automatically closed blocks
don't have.

Funnily enough, C's preprocessor is one of those languages:

#if
....
#endif

As I said above, this is topsy-turvy: the grown-up syntax is relegated
to the preprocessor; the real language has the crappy syntax!

Having end-tags doesn't make Fortran a good language or its 'do'
loop a good syntax.

Why? It works and it's simple. You need 4 things to denote a loop header
with an index variable:

(1) The name of the variable
(2) The start value
(3) The end value
(4) Some keyword to tell the compiler this is a loop statement

Plus whatever supplementary syntax the language stipulates. In modern
Fortran that appears to be:

(5) '=' after the index
(6) ',' between the limits.

Total 6 elements (do i=a,b) . In mine, (2) is optional when it is 1, so
it can be as little as 5 elements (for i to b do), otherwise 7.

C however needs 13 elements in all! Short and snappy.

(Note: Algol68 comments need a trailing # too.)

Yes, I know. I added that '#' for posting only. (Despite '#' is
[pairwise] usable in the Genie context I'm nonetheless using
the classical and portable CO ... CO in my programs instead.)

(Both are poor design choices. Leave off one # or CO, and everthing gets
out of step. And it means you can't comment out code that contains
comments. See it's not just C I can criticise.)

(Oh, right, and obviously also about your language/preferences.)

You tried to assert some superiority by describing Algol68 features, but
forgot that my language was originally based on Algol68 syntax.
Obviously tweaked to get bad parts out.

The whole "C" language is "primitive" (in some respects) if
compared to other HLLs.

Yes. (Why do I find it suprising to see you admit that?)

Where you think a terse DO OD is best others might prefer to see
it documented DO # nothing to do # OD and are delighted if that
"comment" is even standardized by a clear 'NOP' as in DO SKIP OD .

Huh? Empty {} blocks occur in C too; they don't need a comment. Maybe
the contents are yet to be written, or are commented out.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 15/04/2025 15:13, Scott Lurndal wrote:

bart <bc@freeuk.com> writes:

On 15/04/2025 05:57, Rosario19 wrote:

On Mon, 14 Apr 2025 14:18:39 +0200, Janis Papanagnou wrote:

(While there's some "C" stuff in here it contains a lot of non-"C"
samples for comparison. So [OT]-sensible folks may want to skip this
post.)

On 14.04.2025 12:16, bart wrote:

On 14/04/2025 05:23, Janis Papanagnou wrote:

On 13.04.2025 18:39, bart wrote:

[...]

for(let i = 1; i <= 36; i++) {

C for loop is great, but all can be workarounded with goto label

For this specific example (ignore 'let' for C), please explain why it is
better than, say:

FOR(i,1,36) {

Because it can't do this:

for(tp = root; tp != NULL; tp = tp->next)

<Face-palm>

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tue, 15 Apr 2025 17:42:24 +0100
bart <bc@freeuk.com> wrote:

Suppose you have two ways A and B to implement a feature in a
language.

You find that those using A tend to make twice as many mistakes in
that feature, and have more undetectable bugs, as those who use B.

Your job is to choose which of A and B to keep.

Would your decision completely ignore such findings?

I would, if twice as many mistakes amount to very small number. The
same for 100 time as many.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 15.04.2025 16:30, bart wrote:

On 15/04/2025 14:33, Kaz Kylheku wrote:

On 2025-04-15, bart <bc@freeuk.com> wrote:

* Not having to write the variable 3 times (with C not always being
able to detect if they didn't match)

This is indeed a source of errors in C nested loops.

According to Janis Papanagnou, it is 100% the programmer's fault. There
is nothing wrong with the language!

No, there is nothing wrong with the language if you make such errors.

The programmer selects (or constructs) the algorithm, the language has
clear semantics for such simple loop constructs without any irregular
or hidden semantics, and the programmer's task is to know the elements
of the language and transfer the algorithm to a correct coding. - It's self-delusion if you try to blame the language for the mistakes you do.

Janis

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 15/04/2025 17:22, Janis Papanagnou wrote:

On 15.04.2025 16:30, bart wrote:

On 15/04/2025 14:33, Kaz Kylheku wrote:

On 2025-04-15, bart <bc@freeuk.com> wrote:

* Not having to write the variable 3 times (with C not always being >>>> able to detect if they didn't match)

This is indeed a source of errors in C nested loops.

According to Janis Papanagnou, it is 100% the programmer's fault. There
is nothing wrong with the language!

No, there is nothing wrong with the language if you make such errors.

The programmer selects (or constructs) the algorithm, the language has
clear semantics for such simple loop constructs without any irregular
or hidden semantics, and the programmer's task is to know the elements
of the language and transfer the algorithm to a correct coding. - It's self-delusion if you try to blame the language for the mistakes you do.

Suppose you have two ways A and B to implement a feature in a language.

You find that those using A tend to make twice as many mistakes in that feature, and have more undetectable bugs, as those who use B.

Your job is to choose which of A and B to keep.

Would your decision completely ignore such findings?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 15/04/2025 14:19, Kaz Kylheku wrote:

On 2025-04-15, bart <bc@freeuk.com> wrote:

On 15/04/2025 08:17, Janis Papanagnou wrote:

and someone already posted another iteration type on linked lists

for (node = list; node; node = node->next)

These two I get, and I can tell you that they're all WHILE loops. To
make make them tidier, I'd have fewer complaints about them if they
instead looked like this:

while (node = list; node; node = node->next)

That's mostly bike shedding. It could also have been called:

do (node = list; node; node = node->next)

loop (node = list; node; node = node->next)

That's sort of the point. It is not 'for' as is it generally understood.
It's more of a souped-up while.

Thats's fine. But it means a real 'for' loop doesn't exist in C; you
have to emulate it using that 3-way construct, which is naff, and also
error prone.

Lisp called this kind of general variable stepping loop "do"

(do ((var1 init1 step1)
(var2 init1 step2)
...)
(until-this-is-true also-this ... yield-this-result)
do-this
and-this
...)

Naming things can be hard. The reason that the loop is called for
is that most instance of for have a focus on the specific variable
that is initialized, and the guard condition has to do with it
hitting some specific terminating value.

In what I recognise as 'for' loops, any variable is specified only once
in the header. Any initialisation and increment is handled automatically.

The same applies if it loops over a set of values; that might mean
managing some implicit index. But hey, this is a HLL, and it's the
compiler's job to that.

So, you can optionally add extra elements to a while (x).

It would be necessary to either define whether while(x; y) means while
(; x; y) or while (x; y), or to always require either zero or two
semicolons inside (...).

That could have kept 'for' for how it works in other languages (the ones
that haven't just blindly copied C's version!).

Common Lisp uses "for" to indicate several kinds of variable
stepping clauses inside the loop syntax, some of which are:

[4]> (loop for x in '(a b c)
for y = 1 then (1+ y)
for z = (* y 10)
with w = (* y 10)
collect (list x y z w))
((A 1 10 10) (B 2 20 10) (C 3 30 10))

I've looked in the past at CLisp and its loops. My view is that the
number of possibilities it provides is over the job. It's like somebody
was tasked with thinking up as many as possible, and making them all
available.

I don't know what your example does. Are these nested loops? Parallel ones?

My own reduce to this:

for [i,]x in A [when cond] do # i exposes internal index

and the older:

for i [:= A] to/downto B [by C] [when cond] do

Languages like CPython go to town a bit more, and do deconstructing etc. However the only thing I've copied from that is an optional 'else' part.

Unusual loops are rare and the requirements diverse enough that I can't
see the point of trying to provide dedicated features beyond the basics.

For custom loops, people can start off with:

do
.....
end

then add what they like out of ordinary features.

When loop is used to simulate the classic Lisp do loop,
it's done with the "for var = init then step" clauses.

There is a "for var from N to M" clause, as well as "for var below N"
which goes from 0 to N-1.

That's a poor way to do it. I suggested elsewhere using only inclusive
ranges, and using '-1' as a postfix 'operator' to treat it as exclusive.

(Inclusive ranges are more natural:

Monday .. Friday
'A' .. 'Z'
Iterate over the elements in X

People don't expect that first to stop at Thursday, or to only go up to
'Y', or to iterate over all elements except the last!)

Since it can always be trivially be written as:

for (;cond;)

That is simply untidy looking.

But this:

for (index = A ; index <= B; index += 1)

is fine!

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

bart <bc@freeuk.com> writes:

On 15/04/2025 14:19, Kaz Kylheku wrote:

Thats's fine. But it means a real 'for' loop doesn't exist in C; you
have to emulate it using that 3-way construct, which is naff, and also
error prone.

Real for loops _are_ a three-way construct.

135 FOR I=1 TO 10 STEP 2 [BASIC]

for(i = 1; i < 11; i += 2) [C/C++]

do 1 = 1, 10, 2 [FORTRAN]

FOR i OVER i.RANGE DESCENDING
DO
countdown(i)
DONE; [SPRITE]



SPRITE also had:

UNTIL done, notfound
DO
...
IF token = "this"
THEN LOOP_EXIT done
FI;
...
IF i = upb(table)
THEN LOOP_EXIT notfound
FI;
...
OD
CASE
IS done: write("i=", i);
OR notfound write("not found", upb(table));

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2025-04-15, bart <bc@freeuk.com> wrote:

On 15/04/2025 14:19, Kaz Kylheku wrote:

Common Lisp uses "for" to indicate several kinds of variable
stepping clauses inside the loop syntax, some of which are:

[4]> (loop for x in '(a b c)
for y = 1 then (1+ y)
for z = (* y 10)
with w = (* y 10)
collect (list x y z w))
((A 1 10 10) (B 2 20 10) (C 3 30 10))

I've looked in the past at CLisp and its loops. My view is that the
number of possibilities it provides is over the job. It's like somebody
was tasked with thinking up as many as possible, and making them all available.

This is easy to because loop is a macro; you can just write code that
you can distribute as a Lisp source file. Early implementatons of loop
were distributed that way. It's happened that some applications would
"bring their own loop" to work around bugs in a Lisp vendor's.

Inspired by the Lisp loop, I made something like it for Awk
using the GNU C Preprocessor.

This was possible largely in part due to the way the
for ( ... ; ... ; ...) header syntax is. The C-style loop
gives us a target construct into which we can compile everything that we
need from all the multiple clauses.

The manual page for the macro is here:

https://www.kylheku.com/cgit/cppawk/tree/cppawk-iter.1

It is part of the cppawk project:

https://www.kylheku.com/cgit/cppawk/about/

There are regression/coverage test cases for it here:

https://www.kylheku.com/cgit/cppawk/tree/testcases-iter

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 15/04/2025 20:07, Scott Lurndal wrote:

bart <bc@freeuk.com> writes:

On 15/04/2025 14:19, Kaz Kylheku wrote:

Thats's fine. But it means a real 'for' loop doesn't exist in C; you
have to emulate it using that 3-way construct, which is naff, and also
error prone.

Real for loops _are_ a three-way construct.

135 FOR I=1 TO 10 STEP 2 [BASIC]

for(i = 1; i < 11; i += 2) [C/C++]

do 1 = 1, 10, 2 [FORTRAN]

Any step other than 1 is unusual. So Basic and Fortran would typically be:

for i = 1 to 10 # 6 tokens; Basic
do i = 1, 10 # 6 tokens; Fortran
for i = 1, 10 # 6 tokens; Lua
for i to 10 do # 5 tokens; Mine (using default start)
to 10 do # 3 tokens; Mine (when index is not needed)

Let's look at that C again:

for (int i = 1; i < 11; i += 1) # 15 tokens; C

* I've added 'int' for the C, as most of the above don't need a
declaration for the loop index. But it will still be 14 without

* I use += for the increment because you did. ++ saves one token,
but it's still at 13/14 tokens

* All the above can directly use 10 as the upper bound; C has to use
11 when written idiomatically

Even using a step of two, that would only add 2 tokens to the above; C
will still need 14/15 tokens.

Note that C's for-loop is dumb; it merely take three expressions A B C
that can be completely unrelated, and arranges them into a loop:

A; while (B) {...; C}

SPRITE also had:

UNTIL done, notfound
DO
...
IF token = "this"
THEN LOOP_EXIT done
FI;
...
IF i = upb(table)
THEN LOOP_EXIT notfound
FI;
...
OD
CASE
IS done: write("i=", i);
OR notfound write("not found", upb(table));

That's pretty weird, but whatever it does, it's nothing to do with
iterating a variable over a range.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2025-04-15, Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:

On 15.04.2025 16:30, bart wrote:

On 15/04/2025 14:33, Kaz Kylheku wrote:

On 2025-04-15, bart <bc@freeuk.com> wrote:

* Not having to write the variable 3 times (with C not always being >>>> able to detect if they didn't match)

This is indeed a source of errors in C nested loops.

According to Janis Papanagnou, it is 100% the programmer's fault. There
is nothing wrong with the language!

No, there is nothing wrong with the language if you make such errors.

The programmer selects (or constructs) the algorithm, the language has
clear semantics for such simple loop constructs without any irregular
or hidden semantics, and the programmer's task is to know the elements
of the language and transfer the algorithm to a correct coding. - It's self-delusion if you try to blame the language for the mistakes you do.

While it would be close to professional misconduct for an engineer
to deflect responsibility for a problem by blaming tools and materials
(which he or she chose!) it is also the engineer's responsibility to
identify how the nature of the tools contributes to problems.

Programming tools contribute to risk. The more details you have to
specify to solve a problem, that are not checked by machine, the greater
the probability of making a mistake. The severity of a mistake
also depends on tools.

Open-coding something detailed tends to be more risky than using a
verified, encapsulated abstraction which does the same thing, but
figures out some of the details.

The main things developers do wrong is choosing the wrong tool for
the job. In such cases, it can be a fool's errand to try to
catalog how the tool contributed to a problem. You wouldn't have
a "post mortem" meeting about why the hammer failed to drive a screw,
and how it could be improved.

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2025-04-15, bart <bc@freeuk.com> wrote:

Note that C's for-loop is dumb; it merely take three expressions A B C
that can be completely unrelated, and arranges them into a loop:

A; while (B) {...; C}

- In this proposed arrangement, if the "continue" keyword is used in the
loop, it will not execute C. You need:

A; while (B) {...; contin_001: C}

and then use "goto contin_001". The 001 is for uniqueness within
the function, to which labels are scoped.

- the arrangement doesn't produce macros very well using the
ordinary preprocessor. Suppose we want to create loop which
steps by 1 from hither to yon:

#define loop_start(A, B, C) do { A = B; while (A < C) {

#define loop_end(A) A++; } } while (0)

we end up with two macros, where we have to repeat the variable.

With the for loop we can just do

#define loop(A, B, C) for (A = B; A < C; A++)

Good thing we have that for syntax with its compact, encapsulated
header that holds all the parts needed.

If you keep plugging away with the naked "for" without making yourself a convenient macro, that's your problem.

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2025-04-15, bart <bc@freeuk.com> wrote:

Note that C's for-loop is dumb; it merely take three expressions A B C
that can be completely unrelated, and arranges them into a loop:

A; while (B) {...; C}

Note that this problem is not unique to the for() statement. An
assignment statement allows you to arrange three unrelated expressions
together like

A = B + C;

"Doctor, it hurts when I hit my head with a hammer!"
"Then stop doing that."

The key to using the for() statement is to make sure the three
expressions are related appropriately. Many different powerful and
useful ways of using a for() statement have been shown in this thread
that are not equivalent to for(int i=start; i<end; i += increment). Individually, those uses aren't particularly common, but collectively
I've needed each of those uses often enough to be grateful that C has
such a flexible construct to do it with.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2025-04-16, James Kuyper <jameskuyper@alumni.caltech.edu> wrote:

On 2025-04-15, bart <bc@freeuk.com> wrote:

Note that C's for-loop is dumb; it merely take three expressions A B C
that can be completely unrelated, and arranges them into a loop:

A; while (B) {...; C}

Note that this problem is not unique to the for() statement. An
assignment statement allows you to arrange three unrelated expressions together like

A = B + C;

"Doctor, it hurts when I hit my head with a hammer!"
"Then stop doing that."

The key to using the for() statement is to make sure the three
expressions are related appropriately.

The observation is valid that the three expressions often fall into a
pattern by which they can be condensed.

for (var = from; var < to; var++)

can be expressed by a construct which mentions var ony once,
and omits the operators.

You can obtain this with the preprocessor and be reasonably happy.

Similarly, sometimes assignment statements fit patterns which
lead us to want to condense them.

One pattern is

A = A + C

for which we have

A += C

in order to avoid mentioning A twice, and of course for

A = A + 1

we have

++A (as well as A++ which lets us capture the prior value)

C pointer arithmetic affords us a way to condense this pattern also:

A[i] = B[i] + C[i]

in a loop body where these expressions are repeated multiple times,
and are both read and written, we can achieve economy of expression with

double a = &A[i];
double b = &B[i];
double c = &C[i];

*a = *b + *c;

Sometimes code like this shamelessly uses preprocessing, hopefully
confined to a single translation unit.

#define a A[i]
#define b B[i]
#define c C[i]

a = b + c

C provides some decent syntactic sugars to shorten code.

It seems shortsighted to criticize C for having a verbose for loop
construct, given that it can be macroed over, and that other devices
more than make up for it.

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 15.04.2025 22:46, bart wrote:

On 15/04/2025 20:07, Scott Lurndal wrote:

[...]
Real for loops _are_ a three-way construct.

[...]

Any step other than 1 is unusual. [...]

Nonsense. Arithmetic loop steps other than one are noting unusual
and been supported by programming languages (and also been used)
since decades in programming.

Janis

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 16.04.2025 07:19, Janis Papanagnou wrote:

If you have some conditioning that "most" is the programming world
then I suggest to #define MOST_LOOP for (i=0 i<=N; ++i)

LOL! - Should have been #define MOST_LOOP for (i=0 i<N; ++i)

off-by-one error by copy/paste-programming! - All points proven.

Janis

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 15.04.2025 18:42, bart wrote:

On 15/04/2025 17:22, Janis Papanagnou wrote:

On 15.04.2025 16:30, bart wrote:

On 15/04/2025 14:33, Kaz Kylheku wrote:

On 2025-04-15, bart <bc@freeuk.com> wrote:

* Not having to write the variable 3 times (with C not always
being
able to detect if they didn't match)

This is indeed a source of errors in C nested loops.

According to Janis Papanagnou, it is 100% the programmer's fault. There
is nothing wrong with the language!

No, there is nothing wrong with the language if you make such errors.

The programmer selects (or constructs) the algorithm, the language has
clear semantics for such simple loop constructs without any irregular
or hidden semantics, and the programmer's task is to know the elements
of the language and transfer the algorithm to a correct coding. - It's
self-delusion if you try to blame the language for the mistakes you do.

Suppose you have two ways A and B to implement a feature in a language.

You find that those using A tend to make twice as many mistakes in that feature, and have more undetectable bugs, as those who use B.

Your job is to choose which of A and B to keep.

Would your decision completely ignore such findings?

We have a couple decisions to make, some factors are often predefined.
The necessary and possible decisions are made on different levels
depending on the role you have in a software project.

If I'd have a choice in the used language I might or might not use "C" depending on the requirements to fulfill.

To be concrete; it's unlikely that I'll use Algol 68 or "your language"
and it had been the case that we had to use languages like C++ or Java.

If I have a choice in the participating programmers I would certainly
select those programmers that don't program by copy/paste and fail to
create correct code even in trivial cases like 'for' loops.

To be concrete for the factors exposed here; I would not select you for
the programming team; more often than not I see you only complaining
and having issues with understanding of (commonly known) programming
and programming language aspects.

As a pure programmer with a given environment I would use the features
of a language that appears most appropriate. You, OTOH, will obviously
be helpless since you fail even with simple loops in "C" - since that's
what "C" provides as control constructs for loops.

Janis

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 15.04.2025 12:30, bart wrote:

On 15/04/2025 08:17, Janis Papanagnou wrote:

On 14.04.2025 17:22, bart wrote:

On 14/04/2025 13:18, Janis Papanagnou wrote:

[...]

The "C" syntax has actually a flexibility that is very valuable.

The flexibility is the problem, because you have to specify the loop in
such excruciating detail. It is easy to make a mistake which results in
still legal code. And you now have to analyse each loop to see what kind >>> of loop it is:

Well, our opinions obviously differ. I just give you two examples
(and there's many variants of these) of not uncommon 'for' usages...

for (c=0; bitstr; c++)
bitstr &= bitstr-1;

I can't grok that.

It's a simple example of a loop where the condition is not depending
on the counting loop variable. - What is it that you don't understand
here? - That's one example where the "C" loop design decision allows
to express yet more sensible functionality than only simple loops with
counts of 1.

(In case you don't understand the actual operation - which is not the
point of this example - inspect, e.g., K&R and the footnotes there.)

If all you know (and can handle) is a simple counted loop then every
extension may appear to you being strange.

[ meaningless while/for stuff snipped ]

(One of your fundamental problems with "C" seems to be to understand
the 'for' keyword meaning only counted loops with one variable and a
simple +1 increment. - I can't help you here.)

[...]

Suppose you see 'i <= N' as the condition; is that '<=' intentional, or
is it a typo for '<'? It's impossible to tell.

(This is nonsense.)

You can't just say that without explanation. WHY it it nonsense?

It's nonsense because all programmers use the comparison operations
that are necessary; I don't know about you but if I do a primitive
arithmetic loop I start with 0 and compare < against N (the amount
of iterations) or start with 1 and compare <= against N; if that's
what is intended.

I've written code where the logic required comparisons of i < N-1
and also i <= N . So what? - Should I not do that because you are
getting confused when inspecting my code?

It's nonsense on so many levels.

If you have doubts ask the programmer or verify the logic. If you
are the programmer add a comment to make the intention clear. If
you are a project lead define coding standards, coach your team,
invent QA measures, do code reviews.

Take this:

for (i=0 i<=N; ++i)

Most such loops iterate over 0..N-1 inclusive, so would need "<".

(One of your fundamental problems with "C" seems to be to understand
the 'for' keyword meaning only counted loops with one variable and a
simple +1 increment. - I can't help you here.)

If you have some conditioning that "most" is the programming world
then I suggest to #define MOST_LOOP for (i=0 i<=N; ++i)
so that you don't make error and don't get confused respectively.

So, in
your opinion, is that <= a typo, or is the intention to iterate over
0..N inclusive (so N+1 iterations)?

It depends on the context.

Janis

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tue, 15 Apr 2025 11:15:06 +0100, bart wrote:

On 15/04/2025 05:57, Rosario19 wrote:

On Mon, 14 Apr 2025 14:18:39 +0200, Janis Papanagnou wrote:

(While there's some "C" stuff in here it contains a lot of non-"C"
samples for comparison. So [OT]-sensible folks may want to skip this
post.)

On 14.04.2025 12:16, bart wrote:

On 14/04/2025 05:23, Janis Papanagnou wrote:

On 13.04.2025 18:39, bart wrote:

[...]

for(let i = 1; i <= 36; i++) {

C for loop is great, but all can be workarounded with goto label

For this specific example (ignore 'let' for C), please explain why it is >better than, say:

FOR(i,1,36) {

This is 99% of my for-loops. Is it the same reasoning why I have to
write 'break' in 99% of my switch-blocks?

APL has just one char "iota" for represent range example iota_36 would
be the range 1..36

{function w}ApplyToAll iota_36

it is equivalent of above loop

for(;;) it is better, because the eye see where are the initialiation,
where the end of loop condition, where the loop increment or loop
change variables, easier.

There's something about this group which celebrates these annoying
language characteristics which are only useful or meaningful in a tiny >minority of cases: see how wonderful it is for 1% of the time?

i'm not agree, when one has something of complex is better for() loop,
but when has something that is more complex than remain goto label...

That must surely justify them being both a PITA and dangerously error
prone in the vast majority of cases!

when one has used for() loop enought time should find that very easy
and convenient.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tue, 15 Apr 2025 09:25:40 +0200, Janis Papanagnou wrote:

On 15.04.2025 06:57, Rosario19 wrote:

On 13.04.2025 18:39, bart wrote:

[...]

for(let i = 1; i <= 36; i++) {

C for loop is great, but all can be workarounded with goto label

Sure. Or all done with Turing machines. - But why would one want to.

because one not has the for loop, because is need more flexibility in
what code has to make, because one find so easy goto label, that it is
easier of the loop for, even if i think in 80% of cases for loop is
less chars and easier of the loop that use goto label

Maybe a note aside on your comment; I haven't read many specification >documents of contemporary language lately, but many of those old specs
often described the semantics of high-level constructs (like loops) by
an equivalent 'goto' based code pattern.

yes low level is goto label

Janis

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tue, 15 Apr 2025 13:33:21 -0000 (UTC), Kaz Kylheku wrote:

On 2025-04-15, bart wrote:

* Not having to write the variable 3 times (with C not always being
able to detect if they didn't match)

This is indeed a source of errors in C nested loops. Say we have
these macros:

FOR (i, 0, N-1)
FOR (j, 0, i)
...

we are less likely to make some copy paste error like

for (i = 0; i < N; i++)
for (j = 0; j < i; i++)
...

Int he past, I've run into bugs in nested loops, along these lines.

if F is a macro as #define F for
until now i not find any inconvenient for me at last

In loop-heavy code, making a macro like the FOR above might not
be a bad idea.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tue, 15 Apr 2025 13:55:43 +0100, bart wrote:

On 15/04/2025 13:25, Michael S wrote:

On Tue, 15 Apr 2025 11:15:06 +0100
bart wrote:

On 15/04/2025 05:57, Rosario19 wrote:

On Mon, 14 Apr 2025 14:18:39 +0200, Janis Papanagnou wrote:

(While there's some "C" stuff in here it contains a lot of non-"C"
samples for comparison. So [OT]-sensible folks may want to skip
this post.)

On 14.04.2025 12:16, bart wrote:

On 14/04/2025 05:23, Janis Papanagnou wrote:

On 13.04.2025 18:39, bart wrote:

[...]

for(let i = 1; i <= 36; i++) {

C for loop is great, but all can be workarounded with goto label

For this specific example (ignore 'let' for C), please explain why it
is better than, say:

FOR(i,1,36) {

This is 99% of my for-loops. Is it the same reasoning why I have to
write 'break' in 99% of my switch-blocks?

There's something about this group which celebrates these annoying
language characteristics which are only useful or meaningful in a
tiny minority of cases: see how wonderful it is for 1% of the time?

That must surely justify them being both a PITA and dangerously error
prone in the vast majority of cases!

I regularly use two languages with "proper loops" - Matlab/Octave and
VHDL (Ada-like syntax). When writing loops in these languages, I don't
feel any extra convenience over C.

I'm not familiar with those, but the first Ada loop example I googled
for was this:

for Variable in 0 .. 9 loop

99% of variable in my C code it one just a letter lenght

In C that exact example would be:

for (Variable = 0; Variable < 10; ++Variable) {

or maybe:

for (Variable = 0; Variable <= 9; Variable = Variable + 1) {

somethime i use F as macro for "for" so for me above would be:

F(j=0;j<=9;++j)

So, in the Ada:

* Not having to write the variable 3 times (with C not always being
able to detect if they didn't match)

* Not having to either offset the upper limit, or juggle between <
and <=

* Not having to explicitly provide the code to increment the variable

doesn't have ANY extra convenience?

(You can have a 100MB compiler and you still have to tell it how to >increment a loop index! That is plain crazy.)

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tue, 15 Apr 2025 11:30:24 +0100, bart wrote:

for (i=0 i<=N; ++i)

Most such loops iterate over 0..N-1 inclusive, so would need "<". So, in >your opinion, is that <= a typo, or is the intention to iterate over
0..N inclusive (so N+1 iterations)?

(May reply to rest separately.)

the loop enter with i=0
than make i= 1..N N in the count
so would be N+1 times iterations
that are 0..N or 0,1,2,3...,N

<= is not a Typo

i not find the problem

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 16/04/2025 06:19, Janis Papanagnou wrote:

On 15.04.2025 12:30, bart wrote:

(One of your fundamental problems with "C" seems to be to understand
the 'for' keyword meaning only counted loops with one variable and a
simple +1 increment. - I can't help you here.)

And your problem seems to the opposite: being unable to understand that for-loop (perhaps spelled 'do') can be a specialised feature to iterate
one or more variables over a predetermined range or set of values.

Unlike C's for, which is just a gimmick where you bundle three
potentially unrelated expressions and hope for the best.

Everyone here is defending the latter to the death. Why? Apparently the
ONLY argument is 'flexibility'.

Having to writing a simple iteration in such a convoluted and unchecked
manner is much better because - you can use the same syntax to iterate
over a list!

I've written code where the logic required comparisons of i < N-1
and also i <= N . So what? - Should I not do that because you are
getting confused when inspecting my code?

This is worrying. So you have a bunch of code with multiple like this:

for (i=0; i<N; ++)
for (i=0; i<N; ++)
for (i=0; i<=N; ++)
for (i=0; i<N; ++)

And you notice one has <= while the others have <. But according to you,
this is nothing remarkable and raises no flags. Obviously the author
intended to iterate one more time there!

With language-supported iteration, the comparison operator is not
exposed, so the programmer cannot accidentally type the wrong one.

(I see I have ++ and not ++i; never mind. It is telling that it took me
a minute to notice!)

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 16/04/2025 11:29, Rosario19 wrote:

On Tue, 15 Apr 2025 11:30:24 +0100, bart wrote:

for (i=0 i<=N; ++i)

Most such loops iterate over 0..N-1 inclusive, so would need "<". So, in
your opinion, is that <= a typo, or is the intention to iterate over
0..N inclusive (so N+1 iterations)?


(May reply to rest separately.)

the loop enter with i=0
than make i= 1..N N in the count
so would be N+1 times iterations
that are 0..N or 0,1,2,3...,N

<= is not a Typo

i not find the problem

No? What about here:

enum {N=10};
int A[N];

for (int i=0; i <= N; ++i) A[i] = i;

Is there still no problem? Except this will be in the middle of 1000
lines of busy code with longer identifiers and more elaborate expressions.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 16/04/2025 06:35, Janis Papanagnou wrote:

On 15.04.2025 22:46, bart wrote:

On 15/04/2025 20:07, Scott Lurndal wrote:

[...]
Real for loops _are_ a three-way construct.

[...]

Any step other than 1 is unusual. [...]

Nonsense. Arithmetic loop steps other than one are noting unusual
and been supported by programming languages (and also been used)
since decades in programming.

So what are you claiming, that the majority of loops in any given
program will have steps other than +1 or -1?

THAT would be nonsense! For your benefit, I've done a survey of a 30Kloc
C program (not one of mine). It has 181 for-loop statements, of which:

15 are endless loops (for (;;))
23 are either linked traversal or do something weird
143 seems to be simple integer interations

Of those 143, 137 count upwards with a step of +1; 6 count downwards
with a step of -1.

So here, 0% of such loops have a step other than 1. THAT's what I mean
by 'unusual'.

Scot Lurndal gave examples comparing C with BASIC/FORTRAN that used
steps other than one, to back up a claim that they routinely use 3
components. Actually they rarely do.

There is something else: all 181 of those loops used the 'for' keyword.
Which meant I had to painstakingly analyse them one by one to determine
what they were (and probably overlooked some but the figures will be
close enough).

Written in my language, 15 would be 'do' loops; 23 would likely be
'while' loops; and only those 143 would be 'for' loops.

No analysis necessary.

But never, mind, C's for-loop will still be the most superior to
everybody here. I'd have an easier time arguing about religion!

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Wed, 16 Apr 2025 12:32:13 +0100
bart <bc@freeuk.com> wrote:

But never, mind, C's for-loop will still be the most superior to
everybody here. I'd have an easier time arguing about religion!

Who exactly said that it is superior? Surely not me.
I think, most posters here would agree with my stance that C for() is non-ideal. esp. for writer, but good enough.

And it has a minor advantage of being more clear for casual readers
than most "proper" counting loop. When counting loop is written as C
for() loop, a casual reader does not have to consult the manual about
meaning of the 1st, 2nd and 3rd (if present) parameters.

I don't know about you, may be your memory is perfect. Mine is not.
Even with python, a language that I use more often than once per year, remembering whether range(3) means (0,1,2) or (0,1,2,3) is an effort.
Much more so with (modern) Fortran, that I read very rarely. In case of Fortran, it certainly does not help that the principle of do loop is the
same as for loop in Matlab/Octave that I use regularly, but the order of parameters differs.

Oh, now you could interpret a written above as statement of superiority
of C syntax. So, no, it is not. Those are *minor* points.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Kaz Kylheku <643-408-1753@kylheku.com> writes:

On 2025-04-16, James Kuyper <jameskuyper@alumni.caltech.edu> wrote:

On 2025-04-15, bart <bc@freeuk.com> wrote:

Note that C's for-loop is dumb; it merely take three expressions A B C
that can be completely unrelated, and arranges them into a loop:

A; while (B) {...; C}

Note that this problem is not unique to the for() statement. An
assignment statement allows you to arrange three unrelated expressions
together like

A = B + C;

"Doctor, it hurts when I hit my head with a hammer!"
"Then stop doing that."

The key to using the for() statement is to make sure the three
expressions are related appropriately.

The observation is valid that the three expressions often fall into a
pattern by which they can be condensed.

for (var = from; var < to; var++)

can be expressed by a construct which mentions var ony once,
and omits the operators.

You can obtain this with the preprocessor and be reasonably happy.

I'd reject any code that hid a 'for' loop in a preprocessor macro
during review.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

bart <bc@freeuk.com> writes:

On 15/04/2025 20:07, Scott Lurndal wrote:

bart <bc@freeuk.com> writes:

On 15/04/2025 14:19, Kaz Kylheku wrote:

Thats's fine. But it means a real 'for' loop doesn't exist in C; you
have to emulate it using that 3-way construct, which is naff, and also
error prone.

Real for loops _are_ a three-way construct.

135 FOR I=1 TO 10 STEP 2 [BASIC]

for(i = 1; i < 11; i += 2) [C/C++]

do 1 = 1, 10, 2 [FORTRAN]

Any step other than 1 is unusual. So Basic and Fortran would typically be:

for i = 1 to 10 # 6 tokens; Basic
do i = 1, 10 # 6 tokens; Fortran
for i = 1, 10 # 6 tokens; Lua
for i to 10 do # 5 tokens; Mine (using default start)
to 10 do # 3 tokens; Mine (when index is not needed)

Let's look at that C again:

for (int i = 1; i < 11; i += 1) # 15 tokens; C

for(i = 1; i++ <= 10;)

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Michael S <already5chosen@yahoo.com> writes:

On Wed, 16 Apr 2025 12:32:13 +0100
bart <bc@freeuk.com> wrote:

But never, mind, C's for-loop will still be the most superior to
everybody here. I'd have an easier time arguing about religion!

Who exactly said that it is superior? Surely not me.
I think, most posters here would agree with my stance that C for() is >non-ideal. esp. for writer, but good enough.

I disagree with that statement, and I expect most posters here
would also disagree with it.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

bart <bc@freeuk.com> writes:

On 16/04/2025 06:35, Janis Papanagnou wrote:

So here, 0% of such loops have a step other than 1. THAT's what I mean
by 'unusual'.

Sample bias.

Scot Lurndal gave examples comparing C with BASIC/FORTRAN that used
steps other than one, to back up a claim that they routinely use 3 >components. Actually they rarely do.

I made no such claim. You said that for loops were not three-way
constructs - I showed that was not an accurate statement. I made
no claims about anything being 'routine'.

A common construct:

entity *ep = entities[0];
for(size_t i = 0ul; i < MAX_ENTITIES; i++, ep++) {
ep->field = do_something(args);
}

in C++

for(x = map.begin(); x != map.end(); ++x) {
/* process a red-black tree element */
}

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Wed, 16 Apr 2025 14:09:44 GMT
scott@slp53.sl.home (Scott Lurndal) wrote:

bart <bc@freeuk.com> writes:

On 15/04/2025 20:07, Scott Lurndal wrote:

bart <bc@freeuk.com> writes:

On 15/04/2025 14:19, Kaz Kylheku wrote:

Thats's fine. But it means a real 'for' loop doesn't exist in C;
you have to emulate it using that 3-way construct, which is naff,
and also error prone.

Real for loops _are_ a three-way construct.

135 FOR I=1 TO 10 STEP 2 [BASIC]

for(i = 1; i < 11; i += 2) [C/C++]

do 1 = 1, 10, 2 [FORTRAN]

Any step other than 1 is unusual. So Basic and Fortran would
typically be:

for i = 1 to 10 # 6 tokens; Basic
do i = 1, 10 # 6 tokens; Fortran
for i = 1, 10 # 6 tokens; Lua
for i to 10 do # 5 tokens; Mine (using default start)
to 10 do # 3 tokens; Mine (when index is not needed)

Let's look at that C again:

for (int i = 1; i < 11; i += 1) # 15 tokens; C

for(i = 1; i++ <= 10;)

I'd reject this code during review.
Hopefully, you too.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 16/04/2025 13:08, Michael S wrote:

On Wed, 16 Apr 2025 12:32:13 +0100
bart <bc@freeuk.com> wrote:

But never, mind, C's for-loop will still be the most superior to
everybody here. I'd have an easier time arguing about religion!

Who exactly said that it is superior? Surely not me.
I think, most posters here would agree with my stance that C for() is non-ideal. esp. for writer, but good enough.

And it has a minor advantage of being more clear for casual readers
than most "proper" counting loop.

Well, there is less ambiguity about the iteration range. But this is
something that C's 0-based nature has helped create (see below).

When counting loop is written as C
for() loop, a casual reader does not have to consult the manual about
meaning of the 1st, 2nd and 3rd (if present) parameters.

No, you have to analyse the loop instead:

for(pParent=p; pParent; pParent=pParent->pPrior, pSub=pSub->pPrior){
for(p=p->pParent;res && p && p->eType==FTSQUERY_NEAR; p=p->pParent){
for(i=0; zLine[i] && IsSpace(zLine[i]); i++){}

The first challenge is to isolate the condition! That means carefully
counting those ; and , characters. Then figuring out what's going on.

These three clearly are not simple iterations, yet they are all start
'for'. I'd write the third (at least) like this:

i = 0;
while (zLine[i] && IsSpace(zLine[i]) {++i}

Now constrast with a language where you KNOW that 'for' isn't going to
be doing anything whacky. You know there will be a loop index name and
some limits, or a collection of values to loop over:

for index in firstvalue..lastvalue
for x in collection

I don't know about you, may be your memory is perfect. Mine is not.
Even with python, a language that I use more often than once per year, remembering whether range(3) means (0,1,2) or (0,1,2,3) is an effort.
Much more so with (modern) Fortran, that I read very rarely. In case of Fortran, it certainly does not help that the principle of do loop is the
same as for loop in Matlab/Octave that I use regularly, but the order of parameters differs.

When languages used to be 1-based, it was easy. Then 0-based came along,
and typically iteration changed from 1..N inclusive, to 0..N-1 inclusive.

Now, a range may or may not be inclusive. In Python, 0-based, it isn't,
so range(10) or range(0,10) means 0..9 inclusive.

Oh, now you could interpret a written above as statement of superiority
of C syntax. So, no, it is not. Those are *minor* points.

Here's some C code to print the elements of an array:

static char* table[] = {"one", "two", "three", "four", "five"};

for (int i=0; i<sizeof(table)/sizeof(table[0]); ++i)
printf("%d %s\n", i, table[i]);

And here is how I'd write it using the 'minor' advantages of my syntax:

static []ichar table = ("one", "two", "three", "four", "five")

for i, s in table do
println i, s
end

To me, the differences in that for-loop are like chalk and cheese.

(Note that the latter is 1-based, but it is not apparent in the code;
the outputs are numbered 1 to 5. The C is zero-based, and that has to be specified. The outputs are numbered 0 to 4.

Moreover, I could have specified a different array base, and the loop
remains unchanged.)

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 16/04/2025 15:09, Scott Lurndal wrote:

bart <bc@freeuk.com> writes:

On 15/04/2025 20:07, Scott Lurndal wrote:

bart <bc@freeuk.com> writes:

On 15/04/2025 14:19, Kaz Kylheku wrote:

Thats's fine. But it means a real 'for' loop doesn't exist in C; you
have to emulate it using that 3-way construct, which is naff, and also >>>> error prone.

Real for loops _are_ a three-way construct.

135 FOR I=1 TO 10 STEP 2 [BASIC]

for(i = 1; i < 11; i += 2) [C/C++]

do 1 = 1, 10, 2 [FORTRAN]

Any step other than 1 is unusual. So Basic and Fortran would typically be: >>
for i = 1 to 10 # 6 tokens; Basic
do i = 1, 10 # 6 tokens; Fortran
for i = 1, 10 # 6 tokens; Lua
for i to 10 do # 5 tokens; Mine (using default start)
to 10 do # 3 tokens; Mine (when index is not needed)

Let's look at that C again:

for (int i = 1; i < 11; i += 1) # 15 tokens; C

for(i = 1; i++ <= 10;)

So real for loops are a /two-way/ construct?

In any case, that doesn't do the same as the others, as it iterates over
2 to 11 inclusive, not 1 to 10.

You might try 'for (i=0; i++ < 10);)', but there's still a problem: you
have to offset the start value by -1. This mean that to iterate over the
0..9 bounds of 10-element array, you'd have to write:

for (i = -1; i++ < 9;)

It becomes exclusive at the lower end, and top becomes inclusive despite
using '<' instead of '<='.

The real problem is that the index is incremented in the wrong place.
Now look again at that Fortran:

do i = 1, 10 # iterate over 1..10 inclusive
do i = 0, 9 # iterate over 0..9 inclusive

It now looks even better: gorgeously simple, clean, intuitive - and
still shorter.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

bart <bc@freeuk.com> writes:

On 16/04/2025 06:35, Janis Papanagnou wrote:

So here, 0% of such loops have a step other than 1. THAT's what I mean
by 'unusual'.

The files easily accessible to me contain 13965 for statements, of which
596 used a step other than 1.

890 are for iterating over linked lists, such as:

for(f = *opt; f; f = f->next)

117 are for iterating over bits in a bit mask, such as:
for(nLeft=0; !(bitmask & ((u64)1 << nLeft))

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 16/04/2025 15:47, James Kuyper wrote:

bart <bc@freeuk.com> writes:

On 16/04/2025 06:35, Janis Papanagnou wrote:

So here, 0% of such loops have a step other than 1. THAT's what I mean
by 'unusual'.

The files easily accessible to me contain 13965 for statements, of which
596 used a step other than 1.

(I assume you mean other than +1 or -1.)

So about 4%. What tool did you use to determine that?

If I look at sql.c (which includes sqlite3.c), there are 1900
for-statements.

Among those, 40 involve += or -=, usually in the increment part, however
I didn't look too closely. I didn't look for ones like i=i+2.

That would be 2% of the total. But the loops include a substantial
proportion of fanciful for-headers, and the odd increment might relate
to those.

Still, I was replying to someone suggesting my claim of "Any step other
than 1 is unusual." was "Nonsense".

I suggest that 2-4% incidence is 'unusual'. In the two smaller programs
I also looked at, of which I reported one, the incidence was 0% among
/simple iterations/.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

bart <bc@freeuk.com> writes:

On 16/04/2025 15:09, Scott Lurndal wrote:

bart <bc@freeuk.com> writes:

On 15/04/2025 20:07, Scott Lurndal wrote:

bart <bc@freeuk.com> writes:

On 15/04/2025 14:19, Kaz Kylheku wrote:

Thats's fine. But it means a real 'for' loop doesn't exist in C; you >>>>> have to emulate it using that 3-way construct, which is naff, and also >>>>> error prone.

Real for loops _are_ a three-way construct.

135 FOR I=1 TO 10 STEP 2 [BASIC]

for(i = 1; i < 11; i += 2) [C/C++]

do 1 = 1, 10, 2 [FORTRAN]

Any step other than 1 is unusual. So Basic and Fortran would typically be: >>>
for i = 1 to 10 # 6 tokens; Basic
do i = 1, 10 # 6 tokens; Fortran
for i = 1, 10 # 6 tokens; Lua
for i to 10 do # 5 tokens; Mine (using default start)
to 10 do # 3 tokens; Mine (when index is not needed)

Let's look at that C again:

for (int i = 1; i < 11; i += 1) # 15 tokens; C

for(i = 1; i++ <= 10;)

So real for loops are a /two-way/ construct?

In any case, that doesn't do the same as the others, as it iterates over
2 to 11 inclusive, not 1 to 10.

The point was to execute a loop 10 times, which this does.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Wed, 16 Apr 2025 10:47:56 -0400
James Kuyper <jameskuyper@alumni.caltech.edu> wrote:

bart <bc@freeuk.com> writes:

On 16/04/2025 06:35, Janis Papanagnou wrote:

So here, 0% of such loops have a step other than 1. THAT's what I
mean by 'unusual'.

The files easily accessible to me contain 13965 for statements, of
which 596 used a step other than 1.

In quoted statement "1" was meant to cover both +1 and -1.
I would be surprised to find out that non-units strides are relatively
common (say, above 0.1%) outside of several specialized fields, like
linear algebra and image processing.

There are yet other fields where we can encounter increments that are non-constant throughout duration of the loop. Bart would probably say
that such loops do not count, in both senses. I.e. they are not
counting loops, but forms of while loop.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 4/16/25 11:18, Michael S wrote:

On Wed, 16 Apr 2025 10:47:56 -0400
James Kuyper <jameskuyper@alumni.caltech.edu> wrote:

bart <bc@freeuk.com> writes:

On 16/04/2025 06:35, Janis Papanagnou wrote:


So here, 0% of such loops have a step other than 1. THAT's what I
mean by 'unusual'.

The files easily accessible to me contain 13965 for statements, of
which 596 used a step other than 1.

In quoted statement "1" was meant to cover both +1 and -1.

Most of that code was part of packages I installed rather than code that
I myself wrote. I naively assumed that any for loop where someone used
+=, it would be for a stride other than 1 - why use "+=1" rather than
"++"? However, 37 of those cases did in fact use "+= 1". None of them
used "-= 1". Indeed, I didn't find any cases of for statements using -=.

I would be surprised to find out that non-units strides are relatively
common (say, above 0.1%)

559/13965 is about 4%.

outside of several specialized fields, like

linear algebra and image processing.

No, for most of them it was some other reason, such as putting tab stops
after ever 4 characters.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2025-04-16, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:

Kaz Kylheku <643-408-1753@kylheku.com> writes:

On 2025-04-16, James Kuyper <jameskuyper@alumni.caltech.edu> wrote:

[...]

The key to using the for() statement is to make sure the three
expressions are related appropriately.

The observation is valid that the three expressions often fall into a
pattern by which they can be condensed.

for (var = from; var < to; var++)

can be expressed by a construct which mentions var ony once,
and omits the operators.

You can obtain this with the preprocessor and be reasonably happy.

Sure, you *can*, but I wouldn't.

But then you would complain about the unpreprocessed version
being verbose, because it becomes a choice at that point.

For me the raw C-style for loop is clear enough.

I could write a macro like:

#define ITERATE(var, from, to) for ((var) = (from); (var) < (to); (var)++)

but then anyone reading the code has to understand both how C-style
for loops work and how the ITERATE macro works.

Anyone understanding any program has to be prepared to study
numerous definitions, in all categories of definition.

Par for the course.

Does the expansion
use < or <=? What happens if "to" is INT_MAX? Did the author of
the macro get everything right?

If they did get it right, then 37 places where it is being used
are consistently also getting it right, assuming those places
intend for ITERATE(a, b, c) to step an integer or pointer value
over the half-open range[b, c). (This aspect of the macro may
be error-prone, but no language construct can read you mind
as to what primary argument value you intended.)

Mostly I just have to worry about two potential issues in
each of those 37 places: (1) are they stepping the correct
variable? E.g. is any inner loop wrongly "hijacking" an outer
loop's variable? and (2) is the half-open range semantics
correct for that situation?

If the 37 loops are open-coded, I have more material to inspect.
There are more ingredients. Four or five different conventions
might easily be identified among the 37.

Here is the crux of the issue: uses of for loop in C follow
certain recognizeable idioms. You have to stare at the loop for
a few seconds to identify which idiom it is using, and is it
getting it right.

Now if someone else finds that such a macro makes things easier for
them, that's fine. But often, *in my opinion*, such macros make code
harder to read for someone who knows C well.

Also, annoying nonstandard gobbledygook like:

result_t res = strip_layer_2_header(packet, L2_STRIP_GAUSSIAN);

Gee, why can't they just put everything in one main() function,
which is filled with nothing but vocabulary from Section 7 of
ISO C, Library, instead of changing the language? Nouns and verbs are
language, you know.

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Wed, 16 Apr 2025 12:38:07 +0100, bart wrote:

On 16/04/2025 11:29, Rosario19 wrote:

On Tue, 15 Apr 2025 11:30:24 +0100, bart wrote:

for (i=0 i<=N; ++i)

Most such loops iterate over 0..N-1 inclusive, so would need "<". So, in >>> your opinion, is that <= a typo, or is the intention to iterate over
0..N inclusive (so N+1 iterations)?


(May reply to rest separately.)

the loop enter with i=0
than make i= 1..N N in the count
so would be N+1 times iterations
that are 0..N or 0,1,2,3...,N

<= is not a Typo

i not find the problem

No? What about here:

enum {N=10};
int A[N];

for (int i=0; i <= N; ++i) A[i] = i;

Is there still no problem? Except this will be in the middle of 1000
lines of busy code with longer identifiers and more elaborate expressions.

in this case the if the lenght of A is N, the loop has to be

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

so i is in the range 0..N-1
but i never use macro/enum as lengh of arrays, or at last don't
rememeber i have had used that

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2025-04-16, Kaz Kylheku <643-408-1753@kylheku.com> wrote:

On 2025-04-16, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:

Kaz Kylheku <643-408-1753@kylheku.com> writes:

On 2025-04-16, James Kuyper <jameskuyper@alumni.caltech.edu> wrote:

[...]

The key to using the for() statement is to make sure the three
expressions are related appropriately.

The observation is valid that the three expressions often fall into a
pattern by which they can be condensed.

for (var = from; var < to; var++)

can be expressed by a construct which mentions var ony once,
and omits the operators.

You can obtain this with the preprocessor and be reasonably happy.

Sure, you *can*, but I wouldn't.

But then you would complain about the unpreprocessed version
being verbose, because it becomes a choice at that point.

s/would/woudln't/

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 16/04/2025 19:43, Kaz Kylheku wrote:

On 2025-04-16, Kaz Kylheku <643-408-1753@kylheku.com> wrote:

<snip>

But then you would complain about the unpreprocessed version
being verbose, because it becomes a choice at that point.

s/would/woudln't/

s/woudln't/wouldn't/

--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2025-04-16, bart <bc@freeuk.com> wrote:

On 16/04/2025 06:35, Janis Papanagnou wrote:

On 15.04.2025 22:46, bart wrote:

On 15/04/2025 20:07, Scott Lurndal wrote:

[...]
Real for loops _are_ a three-way construct.

[...]

Any step other than 1 is unusual. [...]

Nonsense. Arithmetic loop steps other than one are noting unusual
and been supported by programming languages (and also been used)
since decades in programming.

So what are you claiming, that the majority of loops in any given
program will have steps other than +1 or -1?

Hey Bart, how would you handle a loop like

do x = m to n ...

where m and n are not known until run time, and may be the
extreme values of the type? Like C's INT_MIN and INT_MAX, respectively,
where x is of type int.

Because in this loop, x takes on every possible value of the type,
we cannot have a loop guard which prevents entry of the loop body
based on solely the value of x.

The compilaton strategy we will likely pursue for this will be
a bottom-of-the-loop test. That is to say, after executing
an iteration, if x has the value n, then the loop terminates.

Unfortunately, this pattern doesn't lend itself well to the
for(;;) construct n C.

The idiom for (x = m; x <= n; x++) only works when x may be
incremented even when it is already equal to n.

If the type is singned, like int, and n is INT_MAX, x++
is undefined behavior after the last iteration.

So this is part of the reason why for leaves everything open; the C
programmer can hand-wave away these issues based on the specific use
case of the loop, whose details are in the open, making it obvious that
the idiom doesn't fully generalize to every corner case.

The for construct could use a way of indicating a bottom test,
like, oh, I don't know:

for (decl/expr; : expr ; expr) // or some better way

Here, the : means, jump unconditionally into the first iteration,
and test expr after each iteration, before doing the increment.

Then we can do

for (int i = INT_MIN; : i < INT_MAX; i++)

After the last iteration, i is INT_MAX, and so the test fails.
The loop terminates without performing i++.

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 16/04/2025 21:03, Keith Thompson wrote:

bart <bc@freeuk.com> writes:

On 16/04/2025 06:35, Janis Papanagnou wrote:

On 15.04.2025 22:46, bart wrote:

On 15/04/2025 20:07, Scott Lurndal wrote:

[...]
Real for loops _are_ a three-way construct.

[...]

Any step other than 1 is unusual. [...]

Nonsense. Arithmetic loop steps other than one are noting unusual
and been supported by programming languages (and also been used)
since decades in programming.

So what are you claiming, that the majority of loops in any given
program will have steps other than +1 or -1?

Exactly, because "unusual" and "the majority" are the only
possibilities.

I'm not sure what you're getting at.

If you go back a few posts, Scott Lurndal was (1) trying to make out
that all for loops consist of 3 elements like C; (2) showing examples in
BASIC and FORTRAN that with 'STEP' parts that made them somewhat longer
than otherwise:

"135 FOR I=1 TO 10 STEP 2 [BASIC]

for(i = 1; i < 11; i += 2) [C/C++]

do 1 = 1, 10, 2 [FORTRAN]"

This was misleading: C always needs that third part when incrementing,
*even when the increment is one*, but BASIC and FORTRAN never need it
*unless* the increment is other than one.

So I said 'Any step other than 1 is unusual". Which it is (I've seen
enough code over half a century to know that is true, and I also spent a
year writing Fortran professionally).

To which JP said this:

"Nonsense".

So do you agree with JP here or with me?

And if with me, why are you not having a go at JP; another of your
chummy mates?

And if you agree JP, then same question.

We know your opinion. I for one acknowedge that your opinion
is valid, and you're entitled to hold it. We're just tired
of you making the same point again and again and again,

And I'm tired of people trying to catch me out with stupid, invalid
arguments.

while
misrepresenting those of us who hold different opinions.

What point was JP making when they said "Nonsense", what opinion was
being opined? My reply were only about the prevalence of certain steps
in iterating loops within programming languages.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 16/04/2025 22:43, Kaz Kylheku wrote:

On 2025-04-16, bart <bc@freeuk.com> wrote:

On 16/04/2025 06:35, Janis Papanagnou wrote:

On 15.04.2025 22:46, bart wrote:

On 15/04/2025 20:07, Scott Lurndal wrote:

[...]
Real for loops _are_ a three-way construct.

[...]

Any step other than 1 is unusual. [...]

Nonsense. Arithmetic loop steps other than one are noting unusual
and been supported by programming languages (and also been used)
since decades in programming.

So what are you claiming, that the majority of loops in any given
program will have steps other than +1 or -1?

Hey Bart, how would you handle a loop like

do x = m to n ...

where m and n are not known until run time, and may be the
extreme values of the type? Like C's INT_MIN and INT_MAX, respectively,
where x is of type int.

Because in this loop, x takes on every possible value of the type,
we cannot have a loop guard which prevents entry of the loop body
based on solely the value of x.

I'm not exactly sure what you are asking. Is it a loop like this, here
in my language:

int n:=0

for i in i32.bounds do # ie. i32.min .. i32.max
++n
od

println n

This works fine; after a second or so it displays 4294967296.

However, this languages evaluates using 64 bits. Perhaps this loop may demonstrate the issues better:

for i in i64.bounds do

However, I would estimate it would take 190 years to finish.

I assume you're thinking of C which uses i32 and where comparisons near
the extreme values of the type are problemetical. Or this line in my
language:

for i in i64.max-10 .. i64.max do println i

which doesn't stop (u64 is OK however). That doesn't worry me too much,
I can just add a Note to the language spec warning of UB when a for-loop
bound is at the limits of the type. Where all sorts of other stuff can
happen because of how values wrap.

Then workarounds are needed, for example:

i := a := i64.max-10
b := i64.max

to b-a+1 do
println i++
od

The compilaton strategy we will likely pursue for this will be
a bottom-of-the-loop test. That is to say, after executing
an iteration, if x has the value n, then the loop terminates.

Unfortunately, this pattern doesn't lend itself well to the
for(;;) construct n C.

The idiom for (x = m; x <= n; x++) only works when x may be
incremented even when it is already equal to n.

If the type is singned, like int, and n is INT_MAX, x++
is undefined behavior after the last iteration.

So this is part of the reason why for leaves everything open; the C programmer can hand-wave away these issues based on the specific use
case of the loop, whose details are in the open, making it obvious that
the idiom doesn't fully generalize to every corner case.

The for construct could use a way of indicating a bottom test,
like, oh, I don't know:

for (decl/expr; : expr ; expr) // or some better way

Here, the : means, jump unconditionally into the first iteration,
and test expr after each iteration, before doing the increment.

Then we can do

for (int i = INT_MIN; : i < INT_MAX; i++)

After the last iteration, i is INT_MAX, and so the test fails.
The loop terminates without performing i++.

You're trying too hard. I don't think the language needs to bother
providing solutions, it just needs to specify the limitations.

If the user needs to know about, and remember in the rare instance it
comes up, dedicated language features, then the user can also come up
with their own workarounds as I showed. Eg. in C:

long long int i, a=INT_MIN, b=INT_MAX, n=0;

for (i = a; i<=b; ++i) ++n;

printf("%lld\n", n);

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2025-04-16, bart <bc@freeuk.com> wrote:

On 16/04/2025 22:43, Kaz Kylheku wrote:

On 2025-04-16, bart <bc@freeuk.com> wrote:

On 16/04/2025 06:35, Janis Papanagnou wrote:

On 15.04.2025 22:46, bart wrote:

On 15/04/2025 20:07, Scott Lurndal wrote:

[...]
Real for loops _are_ a three-way construct.

[...]

Any step other than 1 is unusual. [...]

Nonsense. Arithmetic loop steps other than one are noting unusual
and been supported by programming languages (and also been used)
since decades in programming.

So what are you claiming, that the majority of loops in any given
program will have steps other than +1 or -1?

Hey Bart, how would you handle a loop like

do x = m to n ...

where m and n are not known until run time, and may be the
extreme values of the type? Like C's INT_MIN and INT_MAX, respectively,
where x is of type int.

Because in this loop, x takes on every possible value of the type,
we cannot have a loop guard which prevents entry of the loop body
based on solely the value of x.

I'm not exactly sure what you are asking. Is it a loop like this, here
in my language:

int n:=0

for i in i32.bounds do # ie. i32.min .. i32.max
++n
od

println n

This works fine; after a second or so it displays 4294967296.

However, this languages evaluates using 64 bits. Perhaps this loop may demonstrate the issues better:

for i in i64.bounds do

However, I would estimate it would take 190 years to finish.

Sure, but you could have a loop that goes over the last n
values of the range of i64, for a reasonably small n.

I assume you're thinking of C which uses i32 and where comparisons near
the extreme values of the type are problemetical. Or this line in my

Comparisons aren't; gratuitous increments or displacements are.

language:

for i in i64.max-10 .. i64.max do println i

Exactly, small n.

which doesn't stop (u64 is OK however).

What? That's a boogy bug.

That doesn't worry me too much,
I can just add a Note to the language spec warning of UB when a for-loop bound is at the limits of the type.

I will frame these words next time you cricize C of taking some
easy way out and shirking doing the Right Thing with UB.

Where all sorts of other stuff can
happen because of how values wrap.

You can fix all the other stuff at the language level also.

Then we can do

for (int i = INT_MIN; : i < INT_MAX; i++)

After the last iteration, i is INT_MAX, and so the test fails.
The loop terminates without performing i++.

You're trying too hard. I don't think the language needs to bother
providing solutions, it just needs to specify the limitations.

I don't understand why you're not in the C camp with these words.

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

bart <bc@freeuk.com> writes:

On 16/04/2025 21:03, Keith Thompson wrote:

bart <bc@freeuk.com> writes:

If you go back a few posts, Scott Lurndal was (1) trying to make out
that all for loops consist of 3 elements like C;

You again resort to misleading summaries. Classic Troll.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 17/04/2025 00:49, Kaz Kylheku wrote:

On 2025-04-16, bart <bc@freeuk.com> wrote:

language:

for i in i64.max-10 .. i64.max do println i

Exactly, small n.

which doesn't stop (u64 is OK however).

What? That's a boogy bug.

(Yeah. Backend problem which hardcoded signed compared. 'for' iteration
has its own IL instruction.)

That doesn't worry me too much,
I can just add a Note to the language spec warning of UB when a for-loop
bound is at the limits of the type.

I will frame these words next time you cricize C of taking some
easy way out and shirking doing the Right Thing with UB.

I can make it implementation-defined since the behaviour can be
predicted on the targets I will use. But in the language, if the natural
wrap on overflow gives unexpected results, then you have a program bug.

I think what you were alluding to was the implicit increment used to
implement for-loops. Well this is the IL instruction for FOR that I
mentioned above:

(kforup, ..), # B+:=n; goto L when B<=C

The increment is part of its behaviour. At the language level, I could
explain how FOR is implemented, but I'd rather not do that.

A note that upper and lower limits must be in the range i64.min + s ..
i64.max - s (where s is the step size) can suffice.

What's far more useful is that it naturally works with i64 so has limits
4 billion times bigger than you get with C's default 'int' type.

Where all sorts of other stuff can
happen because of how values wrap.

You can fix all the other stuff at the language level also.

How do you fix overflow of A * B?

Then we can do

for (int i = INT_MIN; : i < INT_MAX; i++)

After the last iteration, i is INT_MAX, and so the test fails.
The loop terminates without performing i++.

You're trying too hard. I don't think the language needs to bother
providing solutions, it just needs to specify the limitations.

I don't understand why you're not in the C camp with these words.

I am in the C camp (I said exactly that a few days ago). I just don't
like the way the visible language was designed, and think there are too
many unreasonable UBs.

There are plenty of higher level languages that can deal with this
properly (I guess; I haven't tried them).

Although those that have copied C's 'for'-loop syntax are likely to be
using the same kind of loop iteration that can cause a problem.

Maybe the language can detect overflow, but it won't help, as you want
to loop to stop not abort the program. So it is not a solution.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 17/04/2025 01:59, Scott Lurndal wrote:

bart <bc@freeuk.com> writes:

On 16/04/2025 21:03, Keith Thompson wrote:

bart <bc@freeuk.com> writes:

If you go back a few posts, Scott Lurndal was (1) trying to make out
that all for loops consist of 3 elements like C;

You again resort to misleading summaries. Classic Troll.

You said exactly that:

SL:

Real for loops _are_ a three-way construct.

You gave examples of BASIC and FORTRAN with 3 parts and compared to C
with three parts.

You're the fucking troll, mate.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 17/04/2025 01:26, Keith Thompson wrote:

bart <bc@freeuk.com> writes:

On 16/04/2025 21:03, Keith Thompson wrote:

bart <bc@freeuk.com> writes:

On 16/04/2025 06:35, Janis Papanagnou wrote:

On 15.04.2025 22:46, bart wrote:

On 15/04/2025 20:07, Scott Lurndal wrote:

[...]
Real for loops _are_ a three-way construct.

[...]

Any step other than 1 is unusual. [...]

Nonsense. Arithmetic loop steps other than one are noting unusual
and been supported by programming languages (and also been used)
since decades in programming.

So what are you claiming, that the majority of loops in any given
program will have steps other than +1 or -1?

Exactly, because "unusual" and "the majority" are the only
possibilities.

I'm not sure what you're getting at.

I think the misunderstanding is over the meaning of the rather
vague word "unusual".

It seems to be happening a lot! SL is now claiming he never said what he
did in fact say. JP has their own 'misunderstanding'. All trying to
score some minor victory.

Would it kill anybody here to admit I might be right about something or
that I have a point?

Did you really think that Janis was claiming that "the majority of
loops in any given program will have steps other than +1 or -1"?

Why don't you ask them to clarify?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 17/04/2025 00:49, Kaz Kylheku wrote:

On 2025-04-16, bart <bc@freeuk.com> wrote:

On 16/04/2025 22:43, Kaz Kylheku wrote:

On 2025-04-16, bart <bc@freeuk.com> wrote:

On 16/04/2025 06:35, Janis Papanagnou wrote:

On 15.04.2025 22:46, bart wrote:

On 15/04/2025 20:07, Scott Lurndal wrote:

[...]
Real for loops _are_ a three-way construct.

[...]

Any step other than 1 is unusual. [...]

Nonsense. Arithmetic loop steps other than one are noting unusual
and been supported by programming languages (and also been used)
since decades in programming.

So what are you claiming, that the majority of loops in any given
program will have steps other than +1 or -1?

Hey Bart, how would you handle a loop like

do x = m to n ...

where m and n are not known until run time, and may be the
extreme values of the type? Like C's INT_MIN and INT_MAX, respectively,
where x is of type int.

Because in this loop, x takes on every possible value of the type,
we cannot have a loop guard which prevents entry of the loop body
based on solely the value of x.

I'm not exactly sure what you are asking. Is it a loop like this, here
in my language:

int n:=0

for i in i32.bounds do # ie. i32.min .. i32.max
++n
od

println n

This works fine; after a second or so it displays 4294967296.

However, this languages evaluates using 64 bits. Perhaps this loop may
demonstrate the issues better:

for i in i64.bounds do

However, I would estimate it would take 190 years to finish.

Sure, but you could have a loop that goes over the last n
values of the range of i64, for a reasonably small n.

I assume you're thinking of C which uses i32 and where comparisons near
the extreme values of the type are problemetical. Or this line in my

Comparisons aren't; gratuitous increments or displacements are.

OK, I've had a look in detail at the code I generate for for-loops.

I believe it can be made to work with a test for equality instead of less-than-equal, with the increment done only if unequal. But it's
slightly more elaborate.

It works because, for variable limits for example, it already does a
one-time "<=" check before it enters the loop.

But there is a restriction: the loop index can't be changed by user code
within the loop. (Otherwise it can have a value beyond the limit, and
won't detect that.)

As it happens, my loop indices are usually immutable, but not always. So
the revised loop handling can be limited to the case when the index /is/ immutable.

However, I'm not going to implement that. It's enough to know it is a possibility. This particular issue has not bothered me over 43 years of
using <= compares, even when my ints were only 16 bits; I doubt it will
bite any time soon.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 17/04/2025 03:18, Keith Thompson wrote:

bart <bc@freeuk.com> writes:
[...]

The increment is part of its behaviour. At the language level, I could
explain how FOR is implemented, but I'd rather not do that.

Whereas for a language like C which is defined by a written standard,
the standard *must* specify the behavior at the language level
(not in terms of generated intermediate or machine code).

At the language level, the behaviour of FOR loop variable iterating over
A to B inclusive, simply has the variable assuming each of those values
in turn. It doesn't say how it does that.

However, it becomes more important if the language has anything to say
about the value of the loop variable after the loop terminates (when its
scope is not limited to the loop body as is the case in my language).

Then the value might be B + step or B - step, depending on which way it iterates, using the current implementation.

The fact that
for (int i = INT_MAX-1; i <= INT_MAX; i++);
has undefined behavior can be rigorously inferred from the language definition.

A note that upper and lower limits must be in the range i64.min + s
.. i64.max - s (where s is the step size) can suffice.

What's far more useful is that it naturally works with i64 so has
limits 4 billion times bigger than you get with C's default 'int'
type.

You know, of course, that C's int type is not necessarily 32 bits.
There is no "default" for the width of int. If you had written "with
32-bit int", that would have been clear and correct.

I think it's perfectly reasonable for such discussions to assume 'int'
is 32 bits. And to only qualify it only when it can matter.

For computers in general, that assumption is likely to have held for at
least 20 years, possible even 30.

Or maybe you can tell me where I can buy a computer (not some board with
an embedded microcontroller) where a C compiler for it has an 'int' type
other than 32 bits (with either fewer bits, or more!).

At present it only seems to bother you. Since if it REALLY bothered
anyone here, nobody would be using 'int'; they'd be using int32_t or
long, unless they're happy that their int values and intermediate
calculations would be using only 16 bits.

[...]

Maybe the language can detect overflow, but it won't help, as you want
to loop to stop not abort the program. So it is not a solution.

If you want to implement, say, an Ada-style for loop, detecting
overflow is not an issue at the language level. The issue is that
for the following (I think the Ada syntax is clear enough):

for I in Integer'Last-1 .. Integer'Last loop
// whatever
end loop;

the language semantics specify that the body of the loop must be
executed with I equal to Integer'Last-1, and then with I equal to Integer'Last. It's the compiler's job to figure out how to do that,
either without triggering an overflow or by handling it cleanly enough
that it doesn't change the behavior.

Does it define what value I has when the loop terminates, or is the
scope of I local to the loop body?

C's for loop, which is both lower level and more flexible, does not
impose that particular burden on the compiler. It's up to the
programmer to ensure that a given for loop behaves as desired.

My post a few hours ago said I'd found a way of getting better-defined behaviour, but I wasn't going to implement it.

Well, I have done that test now. It replaces a "<=" compare with "==",
and does the test before any incrementing.

It seems to work. *But* it requires the loop variable to either be
immutable (which it usually is in my language) or not be modified to
have a value above B (for an A to B loop incrementing by +1).

It also affects the value of the loop index after normal termination,
since it will always be B, rather than B+1 etc.

It's workable, but I'm a little happier with the way it was so that
option is disabled.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 17/04/2025 12:16, bart wrote:

On 17/04/2025 03:18, Keith Thompson wrote:

If you want to implement, say, an Ada-style for loop, detecting
overflow is not an issue at the language level.  The issue is that
for the following (I think the Ada syntax is clear enough):

     for I in Integer'Last-1 .. Integer'Last loop
         // whatever
     end loop;

the language semantics specify that the body of the loop must be
executed with I equal to Integer'Last-1, and then with I equal to
Integer'Last.  It's the compiler's job to figure out how to do that,
either without triggering an overflow or by handling it cleanly enough
that it doesn't change the behavior.

Does it define what value I has when the loop terminates, or is the
scope of I local to the loop body?

My experiments show that:

(1) Loop variables only have scope within the loop
(2) Loop variables are read-only; they cannot be modified by user code

This makes it much simpler to get the desired behaviour of a loop index iterating up to the maximum value of the type.

So a comparison with other languages (either C or mine) is not that fair.

Mine can be more restrictive, and I can make it more so (eg. restrict
the scope of loop variables), but I have no interest in reimplementing Ada.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 17/04/2025 19:47, Keith Thompson wrote:

bart <bc@freeuk.com> writes:

Or maybe you can tell me where I can buy a computer (not some board
with an embedded microcontroller) where a C compiler for it has an
'int' type other than 32 bits (with either fewer bits, or more!).

Not the point. It's about what "int" *means*. It doesn't mean "a
32-bit integer".

At present it only seems to bother you. Since if it REALLY bothered
anyone here, nobody would be using 'int'; they'd be using int32_t or
long, unless they're happy that their int values and intermediate
calculations would be using only 16 bits.

POSIX and Windows both guarantee that int is at least 32 bits wide, and
it's perfectly reasonable to rely on those guarantees on those platforms.

It would be so easy for you to get this right, but you don't even
acknowledge the possibility that I might have a valid point.

It's an obscure, pedantic point.

A better one is that if considering only Windows and POSIX (what about
MacOS or Android?), then you admit int will be 32 bits (at least, but
I'm not holding my breath for 64).

That means that if either of those OSes are implied, then we can assume
that 'int' means a 32-byte to near 100% likelihood.

That saves thousands of posters having to qualify every reference to
'int' with '[on POSIX or Windows]' or 'when it is exactly 32 bits'.

That would be ironic if they have been making that assumption in their
source code for years and decades, where it would be critical, but are
not allowed to do so on long-running Usenet discusssions where it
doesn't really matter.

So, like you get tired of my keeping on defending my stances from
attacks on multiple fronts, I get tired of having remember that some specialised hardware that runs C may have a 16-bit int or something
equally unusual.

In that case, why don't I save time by stating:

* Whenever I mention 'int' type in the context of C, it means the
32-bit type

* If I intend it to mean anything other than that, I will say so.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 17/04/2025 20:55, Keith Thompson wrote:

bart <bc@freeuk.com> writes:

Here's what you wrote upthread:

What's far more useful is that it naturally works with i64 so has
limits 4 billion times bigger than you get with C's default 'int'
type.

Here's what you could have written:

What's far more useful is that it naturally works with i64 so has
limits 4 billion times bigger than you get with 32-bit int.

That's clearer, shorter, and correct, and would have avoided this
entire subthread. I would not have commented on it.

But it misses out the important bit. Clearly i64 has 2**32 times the
range of i32; that will be the case in any context.

What's relevant here is that my language's "don't care" 'int' type
defaults to 64 bits, while C's 'int' type, on pretty much any PC from
this century, will default to 32 bits.

Which means people are more likely to encounter problems involving wrap,
or UB.

Whether C's 'int' should have moved to 64 bits on 64-bit machines has
been discussed here in the past.

That would have kicked such problems a /long/ way down the road.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 16.04.2025 16:31, bart wrote:

On 16/04/2025 13:08, Michael S wrote:

[...]

When languages used to be 1-based, it was easy. Then 0-based came along,
and typically iteration changed from 1..N inclusive, to 0..N-1 inclusive.

You should be aware that [simple] linear iterations are conceptually
coupled to arrays. The choice of 0-based arrays and thus iterations is
"useful" for compiler creators of such languages. They allow without
overhead and skill for optimization an efficient array access.

[...]

Oh, now you could interpret a written above as statement of superiority
of C syntax. So, no, it is not. Those are *minor* points.

Here's some C code to print the elements of an array:

static char* table[] = {"one", "two", "three", "four", "five"};

for (int i=0; i<sizeof(table)/sizeof(table[0]); ++i)
printf("%d %s\n", i, table[i]);

(This all exposes quite clearly the low-level characteristics of "C".)

And here is how I'd write it using the 'minor' advantages of my syntax:

static []ichar table = ("one", "two", "three", "four", "five")

for i, s in table do
println i, s
end

To me, the differences in that for-loop are like chalk and cheese.

Sure, many language support newer syntaxes for such things. Even older languages do such abstractions; e.g. Awk[*]

split ("one two three four five", table)
for (i in table)
print i, table[i]

(One of many things I like in this very small but powerful language.)

(Note that the latter is 1-based, but it is not apparent in the code;
the outputs are numbered 1 to 5. The C is zero-based, and that has to be specified. The outputs are numbered 0 to 4.

Moreover, I could have specified a different array base, and the loop
remains unchanged.)

Janis

[*] Read it as "GNU Awk", since in that variant (as opposed to standard
Awk) you can control the 'for' iteration order.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 16.04.2025 16:21, Scott Lurndal wrote:

bart <bc@freeuk.com> writes:

On 16/04/2025 06:35, Janis Papanagnou wrote:

So here, 0% of such loops have a step other than 1. THAT's what I mean
by 'unusual'.

Sample bias.

Scot Lurndal gave examples comparing C with BASIC/FORTRAN that used
steps other than one, to back up a claim that they routinely use 3
components. Actually they rarely do.

I made no such claim. You said that for loops were not three-way
constructs - I showed that was not an accurate statement. I made
no claims about anything being 'routine'.

A common construct:

entity *ep = entities[0];
for(size_t i = 0ul; i < MAX_ENTITIES; i++, ep++) {
ep->field = do_something(args);
}

in C++

for(x = map.begin(); x != map.end(); ++x) {
/* process a red-black tree element */
}

There's also some other options in C++, say, STL's [functional]
'for_each()' or, in the newer standards, the variant we already
saw upthread mentioned as one hiding some "technical details".

Janis

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 16.04.2025 13:32, bart wrote:

On 16/04/2025 06:35, Janis Papanagnou wrote:

On 15.04.2025 22:46, bart wrote:

On 15/04/2025 20:07, Scott Lurndal wrote:

[...]
Real for loops _are_ a three-way construct.
[...]

Any step other than 1 is unusual. [...]

Nonsense. Arithmetic loop steps other than one are noting unusual
and been supported by programming languages (and also been used)
since decades in programming.

So what are you claiming, that the majority of loops in any given
program will have steps other than +1 or -1?

No. I am saying that there's many ways to define and use 'for' loops,
and specifically "C" allows (by using an inherent primitive syntax)
to formulate many useful constructs that are also used regularly in
those languages that support such constructs.

As an implied consequence of that you may derive that if you use only
languages that don't support such constructs you must emulate them in
other ways in those languages. (This will naturally not be directly
countable in your preferred statistics.)

Also if you are using a language with more flexible 'for' loops but
you are not using that flexibility - because you haven't learned it,
you just don't grok it, or deliberately abstain from it because, say,
of some dogma that 'for' loops are only "real" 'for' loops if you use
them just in sequential traversing of integers with increments of 1 -
that you will also not see them.

[...]

But never, mind, C's for-loop will still be the most superior to
everybody here.

(I cannot speak for "everybody" as you seem to prefer.)

My own opinion I already stated more than one time; it boils down to:
I dislike "C" syntax in general. I like the flexibility of "C". The
latter is part of the reason why I use that syntactically "inferior"
language in some private programming.

I'd have an easier time arguing about religion!

(But you are arguing all the time in a religious manner already.)

Janis

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 17.04.2025 02:26, Keith Thompson wrote:

bart <bc@freeuk.com> writes:

On 16/04/2025 21:03, Keith Thompson wrote:

bart <bc@freeuk.com> writes:

On 16/04/2025 06:35, Janis Papanagnou wrote:

On 15.04.2025 22:46, bart wrote:

On 15/04/2025 20:07, Scott Lurndal wrote:

[...]
Real for loops _are_ a three-way construct.

[...]

Any step other than 1 is unusual. [...]

Nonsense. Arithmetic loop steps other than one are noting unusual
and been supported by programming languages (and also been used)
since decades in programming.

So what are you claiming, that the majority of loops in any given
program will have steps other than +1 or -1?

Exactly, because "unusual" and "the majority" are the only
possibilities.

I'm not sure what you're getting at.

I think the misunderstanding is over the meaning of the rather
vague word "unusual".

Did you really think that Janis was claiming that "the majority of
loops in any given program will have steps other than +1 or -1"?

The "majority" is as a typical phrase introduced by bart as sort of
substitute for an argument. (I usually avoid claims about presumed "majorities", about what "all" or "most" people here or everywhere
else do.)

It can be easily looked up what I wrote; but bart regularly just
moves goalposts when he's lost, instead of accepting the obvious
facts (or other opinions based on experiences or else).

To reformulate (from memory) some basics I actually said...

Statistics of 98% for simple loops are close to reality, IMO.
Increments of +1/-1 were the rationale for Pascal's decision to
support just such primitive loops.[*]
You are lacking flexibility with only such primitive loops.
Many language provided support more more types of useful loops.
"C" loops have a flexibility that I appreciate and that I use.
Statistical numbers have obviously changed for non-simple loops
for languages that allow such usages.
(...and maybe some more that I don't recall any more.)

Janis

[*] I'd like to take the opportunity to say that Pascal supports
more than just simple "counted" loops; you can also iterate over
any "scalar"[**], say, if you have an 'enum' type "red,blue,green"
you can iterate from "red" to "green".

[**] "Scalar" with non-mathematical meaning; every countable type.

[...]

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 18/04/2025 14:01, Janis Papanagnou wrote:

On 16.04.2025 16:31, bart wrote:

On 16/04/2025 13:08, Michael S wrote:

[...]

When languages used to be 1-based, it was easy. Then 0-based came along,
and typically iteration changed from 1..N inclusive, to 0..N-1 inclusive.

You should be aware that [simple] linear iterations are conceptually
coupled to arrays. The choice of 0-based arrays and thus iterations is "useful" for compiler creators of such languages. They allow without
overhead and skill for optimization an efficient array access.

[...]

Oh, now you could interpret a written above as statement of superiority
of C syntax. So, no, it is not. Those are *minor* points.

Here's some C code to print the elements of an array:

static char* table[] = {"one", "two", "three", "four", "five"};

for (int i=0; i<sizeof(table)/sizeof(table[0]); ++i)
printf("%d %s\n", i, table[i]);

(This all exposes quite clearly the low-level characteristics of "C".)

It highlights three things that C manages to make quite a meal out of,
despite them being trivially fixable even in such a low-level language:

* The for-loop as has been discussed at length

* Getting at the length of a fixed-size array

* Needing to use format codes to print things

(I don't want to know how you can use macros to mitigate some of these;
at that point it's already failed.)

for i, s in table do
println i, s
end

To me, the differences in that for-loop are like chalk and cheese.

Sure, many language support newer syntaxes for such things. Even older languages do such abstractions; e.g. Awk[*]

split ("one two three four five", table)
for (i in table)
print i, table[i]

(One of many things I like in this very small but powerful language.)

I had to check your claims:

* Awk primarily uses a C-style for loop; using 'for in' is an
alternative (it's not clear if this is specific to gnu-Awk)

* 'i in table' iterates over /indices/, not values as is more typical of languages that support 'in'.

(In my stuff, I'd need 'i in table.bounds' to get at the indices, or use
an auxiliary loop variable as shown above.)

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 18/04/2025 14:37, Janis Papanagnou wrote:

On 17.04.2025 02:26, Keith Thompson wrote:

bart <bc@freeuk.com> writes:

On 16/04/2025 21:03, Keith Thompson wrote:

bart <bc@freeuk.com> writes:

On 16/04/2025 06:35, Janis Papanagnou wrote:

On 15.04.2025 22:46, bart wrote:

On 15/04/2025 20:07, Scott Lurndal wrote:

[...]
Real for loops _are_ a three-way construct.

[...]

Any step other than 1 is unusual. [...]

Nonsense. Arithmetic loop steps other than one are noting unusual
and been supported by programming languages (and also been used)
since decades in programming.

So what are you claiming, that the majority of loops in any given
program will have steps other than +1 or -1?

Exactly, because "unusual" and "the majority" are the only
possibilities.

I'm not sure what you're getting at.

I think the misunderstanding is over the meaning of the rather
vague word "unusual".

Did you really think that Janis was claiming that "the majority of
loops in any given program will have steps other than +1 or -1"?

The "majority" is as a typical phrase introduced by bart as sort of substitute for an argument. (I usually avoid claims about presumed "majorities", about what "all" or "most" people here or everywhere
else do.)

It can be easily looked up what I wrote; but bart regularly just
moves goalposts when he's lost, instead of accepting the obvious
facts (or other opinions based on experiences or else).

To reformulate (from memory) some basics I actually said...

Statistics of 98% for simple loops are close to reality,

I haven't been able to find that post. In any case, it was not in the
sequence of posts stemming from this one:

* Scott Lurndal (SL) makes a claim that all 'real' for-loops have 3
parts, like C's for(A; B; C) [point 1]

* He gave example of such loops in C, Basic and Fortran ...

* ... but used a step of +2 in those Basic and Fortran examples in
order to contrive to give them a third part [point 2]

This is where I complained that such a step in Basic and Fortran was
'unusual' (in fact it's so rare then I wasn't even sure of the syntax),
and which you called out as 'Nonsense'.

Later on:

* SL posts an example of 2-part C for-loop, which contradicts his claim
of all 'real' for loops having 3 parts [point 3] ...

* ... which also turns out to be highly incorrect [point 4]

What's puzzling me is this: why are letting those Points 1, 2, 3 and 4
go, but aiming all of your criticisms at me?

In fact you're still at it! Eg: "but bart regularly just moves
goalposts". So SL didn't move goalposts?

Regarding Point 4, nobody picked up on it except for Michael S.

Not you, nor KT or JK who are usually pedantic about such matters.

Yet I state something which is actually correct, you call that nonsense,
and everybody defends you and slams me!

Clear persecution, gaslighting, or both?

Please take a close look at your posting decisions: why you consistently
attack my posts, but let dubious posts from others slide.

IMO.
Increments of +1/-1 were the rationale for Pascal's decision to
support just such primitive loops.[*]
You are lacking flexibility with only such primitive loops.
Many language provided support more more types of useful loops.
"C" loops have a flexibility that I appreciate and that I use.
Statistical numbers have obviously changed for non-simple loops
for languages that allow such usages.

This is 'my' flexible loop:

do
....
od

Add whatever you like in place of ....

C doesn't have a dedicated endless loop; it has to be either while(1) or (again!) for(;;). It might seem a small point, but it means I
acknowledge the importance of such a fundamental construct. It also
shows I don't don't consider it either a 'while' loop, or a 'for'.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 16.04.2025 11:45, Rosario19 wrote:

On Tue, 15 Apr 2025 09:25:40 +0200, Janis Papanagnou wrote:

On 15.04.2025 06:57, Rosario19 wrote:

On 13.04.2025 18:39, bart wrote:

[...]

for(let i = 1; i <= 36; i++) {

C for loop is great, but all can be workarounded with goto label

Sure. Or all done with Turing machines. - But why would one want to.

because one not has the for loop, because is need more flexibility in
what code has to make, because one find so easy goto label, that it is
easier of the loop for, even if i think in 80% of cases for loop is
less chars and easier of the loop that use goto label

(Note my question above was rhetorical. - Turing machine programs is
not something you should consider as scale for what we usually do in programming.)

Of course, if all you have is an assembler language then "all" you
have are jumps. (Note: again an accentuated formulation of the point,
but I'm confident you understand what I'm trying to say.)

If, for common loop conditions, it's easier for someone to use gotos
than to use typical loop constructs then I suggest that this person
should not apply for a programmers' job.

The "number of characters" in a syntactical construct is IMO not the
most relevant or primary factor. But abstractions in languages often
coincide with much terser formulations. And abstractions is what aids
in programming non-trivial systems. I would abstain from gotos, but
because of the "number of characters" to type or to spare.

Janis

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 16.04.2025 13:01, bart wrote:

On 16/04/2025 06:19, Janis Papanagnou wrote:

On 15.04.2025 12:30, bart wrote:

(One of your fundamental problems with "C" seems to be to understand
the 'for' keyword meaning only counted loops with one variable and a
simple +1 increment. - I can't help you here.)

And your problem seems to the opposite: being unable to understand that for-loop (perhaps spelled 'do') can be a specialised feature to iterate
one or more variables over a predetermined range or set of values.

Why do you think so? - I've given enough examples where you could
have easily seen that I'm able to take advantage for my programming
of any loop concept that languages provide, and I've done so, from
Pascal's simple forms, over Simula and Algol 68 loops, to "C"/C++
loops and loop algorithms, or Unix Shell's or Awk's loop constructs.

But if I'd want to use some flexibility of one language and don't
have it available in another language I'll have to work around it.
And, vice versa, if I have that flexibility, why not use it.

Unlike C's for, which is just a gimmick where you bundle three
potentially unrelated expressions and hope for the best.

It's nothing to do with hope. (Your religious approach here is not
very useful if you want to work as [or become] a serious programmer.)
If you are intellectually incapable of managing "C" loops I cannot
help you. - But I have sympathy for you, and can feel your pain if
you're programming in "C" given what you are repeatedly complaining
about.

Everyone here is defending the latter to the death. Why? Apparently the
ONLY argument is 'flexibility'.

Why do you think so? - Flexibility is what "C"'s loop provides; it's
one of the strengths of this loop. - Your agenda and opinion on that
seems to be different, you certainly cannot see or acknowledge that
flexibility and instead try to invalidate that fact repeatedly by
red herrings.

I see that you're priorities are, as you've shown, for example, how
many characters you have to type, or whether you have do..od syntaxes
available as part of the language.

I cannot believe that you never used any of the possibilities that
"C" loops provide us. But okay, it's anyway meaningless what you do.

Having to writing a simple iteration in such a convoluted and unchecked manner is much better because - you can use the same syntax to iterate
over a list!

I understand that you want a primitive loop being available. - And
if that's such a pain that "C" doesn't have it I'd suggest you to
switch to another language; for your private stuff you can do what
you like, there's no prerequisites or boundary conditions imposed
upon you.

I've written code where the logic required comparisons of i < N-1
and also i <= N . So what? - Should I not do that because you are
getting confused when inspecting my code?

This is worrying. So you have a bunch of code with multiple like this:

for (i=0; i<N; ++)
for (i=0; i<N; ++)
for (i=0; i<=N; ++)
for (i=0; i<N; ++)

No. I have written code as I wrote it - still quoted above - not as
you made it up. I haven't said anything else about it. - Only that I
have no issues to apply every form as algorithmic demands require it.

And you notice one has <= while the others have <. But according to you,
this is nothing remarkable and raises no flags. Obviously the author
intended to iterate one more time there!

Yes, different contexts require different implementations.

(It appears strange to me that your programs look all the same. And,
honestly, I cannot believe that; I think you're as usual just making
that up.)

With language-supported iteration, the comparison operator is not
exposed, so the programmer cannot accidentally type the wrong one.

Obviously.

(I see I have ++ and not ++i; never mind. It is telling that it took me
a minute to notice!)

Get some glasses?

Janis

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

bart <bc@freeuk.com> writes:

On 18/04/2025 14:37, Janis Papanagnou wrote:

* Scott Lurndal (SL) makes a claim that all 'real' for-loops have 3
parts, like C's for(A; B; C) [point 1]

Again you mischaracterize what was stated. I simply
pointed out that most major programming languages have three component
looping constructs using the 'for' keyword, including C.

I made no claim about which percentage of real-world uses of the
'for' construct used all three parts.

I do think your constant harping on a well-established and widely-used
language that will never change to satisfy your personal idiosyncrocies
is rather pointless, other than simple trolling.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 18/04/2025 17:58, Scott Lurndal wrote:

bart <bc@freeuk.com> writes:

On 18/04/2025 14:37, Janis Papanagnou wrote:

* Scott Lurndal (SL) makes a claim that all 'real' for-loops have 3
parts, like C's for(A; B; C) [point 1]

Again you mischaracterize what was stated. I simply
pointed out that most major programming languages have three component looping constructs using the 'for' keyword, including C.

Apart from C, simple iteration via a loop index has 4 things that need
to be denoted:

- Some keyword to say this is such a loop

- The loop index variable

- The start value

- The end value

Many can have an /optional/ step (or means to reverse the order) in the
odd cases where that is necessary, making 4/5 if you want to be formal.

C is quite different; it is merely 3 arbitrary expressions, the middle
one of which is used as a loop terminating condition (tested notionally
at the start of the loop).

But in cases where it is used to emulate the kind of loop described
above, then the same applies, except that:

- It will always be 5 parts (the step always has to be accounted for)

- Nearly everthing about how it works has to be imparted to the
compiler:
- The actual expression to initialise the variable
- The exact expression used for the terminating condition
- The exact expression used for incrementing to loop index

- The end value that appears in the terminating condition is
frequently offset (also can also be the case in real for-loops
used in 0-based languages)

- A loop which counts down may well have a quite different pattern
from an upward counting one

So a comparison between C for-loops and more formal ones is not that meaningful.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 16.04.2025 13:01, bart wrote:
...

Unlike C's for, which is just a gimmick where you bundle three
potentially unrelated expressions and hope for the best.

If all you can do is "hope for the best", you're doing it wrong. It's
your job to ensure that they are not arbitrary unrelated expressions,
but correctly related expressions, and that's no different from your responsibility for all of the other expressions that make up your
program. If you find that problematic, you shouldn't be programming in
any language, but certainly not in C.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 18/04/2025 19:10, James Kuyper wrote:

On 16.04.2025 13:01, bart wrote:
...

Unlike C's for, which is just a gimmick where you bundle three
potentially unrelated expressions and hope for the best.

If all you can do is "hope for the best", you're doing it wrong. It's
your job to ensure that they are not arbitrary unrelated expressions,
but correctly related expressions, and that's no different from your responsibility for all of the other expressions that make up your
program.

If you find that problematic, you shouldn't be programming in

any language, but certainly not in C.

I see it didn't take you long to get to the personal insult. What is it
with this group?

My remarks were about what C call's 'for', being a very low level
construct, even at this level of language.

The language will not check that those three parts are correct for the
loop you are trying to express, because there is no way for it to know that.

So that if you do make a mistake, it can't help you, unless it fails incidentally for some other reason. This is where you cannot rely on the compiler, and hence my remark.

See recent posts by JP where they used "<=" instead of "<", and by LP
where they used "N" instead of "N-1".

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.

It's a bit of a cheek to suggest that if people tend to make more compiler-undetectable errors because C's FOR is dumb, that they should
give up programming.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 19.04.2025 00:27, bart wrote:

On 18/04/2025 19:10, James Kuyper wrote:

On 16.04.2025 13:01, bart wrote:
...

Unlike C's for, which is just a gimmick where you bundle three
potentially unrelated expressions and hope for the best.

If all you can do is "hope for the best", you're doing it wrong. It's
your job to ensure that they are not arbitrary unrelated expressions,
but correctly related expressions, and that's no different from your
responsibility for all of the other expressions that make up your
program.

If you find that problematic, you shouldn't be programming in
any language, but certainly not in C.

I see it didn't take you long to get to the personal insult. What is it
with this group?

You have been repeatedly hinted that the problems you have are
primarily on your side. You're constantly blaming the language.
You are obviously incapable of writing correct "C" code.

You still don't get it that *you* are the biggest obstacle to
your success. And that you're repeating your whining about "C"
and everything instead of stop posting tons of repetition, and
instead thinking about what's said. Or just learning the basics
would be more advantageous to you. - But you decided to continue
your nonsense instead, as we see below.

My remarks were about what C call's 'for', being a very low level
construct, even at this level of language.

Certainly not "very low" (compared, e.g., to gotos) but not as
abstract as in other HLLs; we all know that, and also explicitly
stated that many many times. Why are you to stubbornly ignoring
the facts that were written and stated.

The language will not check that those three parts are correct for the
loop you are trying to express, because there is no way for it to know
that.

Yes. Because "C" loops are different from other loop concepts. And
the "three parts" are semantically not related. Accept that if you
intend to program in "C".

So that if you do make a mistake, it can't help you, unless it fails incidentally for some other reason. This is where you cannot rely on the compiler, and hence my remark.

You can make mistakes in every language and in every communication
and anywhere else. - Your postings are a source of mistakes, and
the bad thing is not the mistakes; it is that you are *repeating*
your mistakes on and on.

See recent posts by JP where they used "<=" instead of "<", and by LP
where they used "N" instead of "N-1".

If you mean my post where I said "all points proven"...

I copy/pasted code from your post, but selected the wrong example.
After posting and rereading I immediately noticed that and corrected
that. - This was no "C" loop issue, it was a text copy/paste issue.
It was _my_ [copy/paste] mistake (not a "C" language design mistake).

Do you understand that? - If not try to not instantly write another
post but first take 10 minutes to understand what was written.

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.[*]
If that's all you can intellectually handle you're obviously a lousy
programmer (and far from a software engineer).

It could be so simple; don't use "C" and all your problems are gone.
(Well, at least all your "C" related problems.)

[*] And the implementations I recall also didn't get implementation
correct for use with real-valued loops. (Just BTW.)

It's a bit of a cheek to suggest that if people tend to make more compiler-undetectable errors because C's FOR is dumb, that they should
give up programming.

If you cannot handle elementary things you should give up programming.
(Or use it for your personal purposes only and stop bothering other
people with your personal problems.)

Janis

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 18.04.2025 19:27, bart wrote:

[...]

C is quite different; it is merely 3 arbitrary expressions, the middle
one of which is used as a loop terminating condition (tested notionally
at the start of the loop).

They're not "arbitrary".

They are chosen by the software designer to fulfill the demands.
You've already and often demonstrated that you have problems to
grok non-trivial loops. But I'll anyway support you with another
example (here from C++, but the principle is the same)

for (unsigned int i = 0; aa.notEmpty(); i++)
for (Arabic a = a2r_tab[i].arabic;
aa.contains(a);
aa.remove(a))
r += a2r_tab[i].roman;

for (unsigned int i = 0; rr.notEmpty(); i++)
for (Roman r = r2a_tab[i].roman;
rr.contains(r);
rr.remove (r))
a += r2a_tab[i].arabic;

All elements in the nested loops are algorithmically connected,
they are not "arbitrary". - I don't expect that (without context
or comments) anyone understands that; the point is that you just
cannot formulate the algorithm with primitive loops. And another
point is that these algorithms are using these _equivalent_ loop
hierarchies despite working on completely different data types,
so the (for you probably perceived as unrelated) interconnection
of the loop elements in the loop hierarchy is meaningful.

So I think above you meant to say that the loop expressions are
not "tightly coupled". - Yes, they are not, and thus can be used
in more advanced algorithmic contexts.

Janis

[...]

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 18.04.2025 16:34, bart wrote:

On 18/04/2025 14:01, Janis Papanagnou wrote:

Sure, many language support newer syntaxes for such things. Even older
languages do such abstractions; e.g. Awk[*]

split ("one two three four five", table)
for (i in table)
print i, table[i]

(One of many things I like in this very small but powerful language.)

I had to check your claims:

* Awk primarily uses a C-style for loop; using 'for in' is an
alternative (it's not clear if this is specific to gnu-Awk)

The 'in' loop was always available and is also POSIX standard.

My footnote (you stripped it)....

[*] Read it as "GNU Awk", since in that variant (as opposed to standard
Awk) you can control the 'for' iteration order.

...pointed to a non-standard GNU extension how to iterate over Awk's associative arrays; the standard provides no guarantee about the order
of traversal. GNU Awk allows to iterate in various ways; by index or
by value, in numeric or alphabetic order, ascending or descending.
These options are a very useful extension.

* 'i in table' iterates over /indices/, not values as is more typical of languages that support 'in'.

Yes. - But see what I wrote about traversal options in GNU Awk.

Janis

[...]

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.

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?

In fact, WHY does Awk have that other kind of loop? Since the primitive
form can express it just as well.

What are the advantages? Say somebody said, if you can't express a loop
using C-style, and need to rely on 'for-in', then you're a lousy programmer.

Let's go the other way and say C had no loops at all, and somebody
advocating for loop statements was told that if they couldn't handle
'if', 'goto' and labels, then *they* were a lousy programmmer?

Your arguments are ludicrous, sorry.

Effectively you are arguing for there to be no higher level languages,
because anyone who wants them must also be incapable of understanding
and using what there is.

It could be so simple; don't use "C" and all your problems are gone.
(Well, at least all your "C" related problems.)

Ha! I generally don't.

The 1% of my coding that involves actual C is enough.

If you cannot handle elementary things you should give up programming.

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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:

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.

Why is that not primitive? It is about the most restricted loop
concept one can think of; 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.

However C's for-loop genuinely *IS* primitve.

Yet has higher expressiveness. We disagree what "primitive" means;
so it's hard to continue the discussion below since we're speaking
different languages, obviously.

I cannot program non-trivial or complex loops with Pascal or BASIC,
they are too restricted (to just one application way), they're too
primitive. We've provided many examples in this thread.

While "C" based its loop on primitive building blocks (statements
and conditions) you can use in the loop all sorts of concrete "C"
building blocks, including an assignments for the initializations
and an increment for the next iteration; as support of a special
case for the simple, primitive forms as found in other languages.

[...]

Suppose that C had both its primitive loop, and one like Basic's (or
like Awk's); would that be better? If so, why?

The BASIC dialects I know of supported only one type of loop; the
simple arithmetic loop. As opposed to Pascal's loop it's possible
to iterate over real arithmetic ranges, though, but that's it.

Awk decided to support two types of loops. The 'in' loop is the
"normal" loop (the arithmetic loop is, for reasons obvious to me,
the extension); since Awk supports only one data structure, namely
associative arrays (and no indexed arrays) you need some iteration
construct that iterates over the keys; "for (key in array)". The
arithmetic loop is there because functions like 'split()' create
associative entries with keys "1", "2", etc. (not numeric indices
1, 2, etc.). But with the implicit type coercion an arithmetic
'for' loop numbers get converted to strings used as key in Awk's
associative arrays. Awk is a higher level language than "C" is,
its array type is more powerful than the indexed arrays we find
in "C". So there's different requirements.

I understand that the "C" language designers decided to not provide
some additional form of loops; that's IMO a sensible decision given
what low-level language "C" is. To define its loops in a flexible
form by building blocks as we know them from other places in the
"C" language makes perfectly sense.

I don't need a second loop in "C". I know it would help you to not
make the errors you seem to regularly make as you say.

In fact, WHY does Awk have that other kind of loop? Since the primitive
form can express it just as well.

No. You have a complete misconception about that. In all respects.
Read what I explained above to get some clue about Awk.

[...]

Effectively you are arguing for there to be no higher level languages, because anyone who wants them must also be incapable of understanding
and using what there is.

(I don't understand what you write here. But what you think is anyway meaningless here since I already _wrote_ what I _intended_ to say and
that needs no (mis-)interpretation of you.)

[...]

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.

Fine. I can completely understand your desire of using HLLs. That's
what I like as well, HLLs. - Just give up considering "C" a HLL and
stop asking about pointless abstractions in "C". - As opposed to Awk
you don't have associative arrays that make an 'in' loop necessary,
and you can do anything with "C" loops that is necessary, much more
than with some other languages' (of higher level or not) restricted
loops. You may not make use of "C"'s loop flexibility, you may not
need it for your application cases, yet it's something that's very
useful (as shown in many examples). If you can't handle "C" loops
don't use that language. Why are you here, in CLC; just to complain?

Janis

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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:

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.

Why is that not primitive? It is about the most restricted loop
concept one can think of;

With the optional step (which is so uncommonly used that I'd forgotten
it even had it), it handles the vast majority of loops where you want a variable to iterate over a range.

That includes everything that Algol68 loops do that use 'for'. ('While'
is an early exit that can achieved with if/goto, but is anyway a feature
of 'for' that is uncommon.)

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?

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

However C's for-loop genuinely *IS* primitve.

Yet has higher expressiveness.

So has 'if' and 'goto'. (I think we've been here before!)

We disagree what "primitive" means;
so it's hard to continue the discussion below since we're speaking
different languages, obviously.

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!

But it eventually got dropped as /it was never used/. Why would it? I
already head the dedicated 'for' for iterations. To express the above
loop using 'cfor' meant writing:

cfor i := a, i <= b, ++ i do

Four extra lots of info (2nd i, <=, ++, 3rd i) , which I needed to get
just right. No thanks.

If you were me, would you have instead have got rid of the dedicated
'for', and kept only 'cfor'? Be honest!

Since that is exactly what you have been saying about C's 'for'; you
don't /want/ a better 'for' in C, even if it was in addition to the
current 'for': 'there is nothing wrong with latter, and anyone who can't
hack it should give up programming'.

I understand that the "C" language designers decided to not provide
some additional form of loops; that's IMO a sensible decision given
what low-level language "C" is.

Mine is too. The original version was even lower level and simpler and
smaller, but it still had PRINT and FOR.


To define its loops in a flexible

form by building blocks as we know them from other places in the
"C" language makes perfectly sense.

I don't need a second loop in "C". I know it would help you to not
make the errors you seem to regularly make as you say.

Lots of people do.

In fact, WHY does Awk have that other kind of loop? Since the primitive
form can express it just as well.

No. You have a complete misconception about that. In all respects.

Really? So why does this work:

split ("one two three four five", table)

for (i=1; i<=5; i++)
print i, table[i]

I thought you said Awk didn't support indexed arrays? (Wrap in 'BEGIN
{...}' for a complete program.)

don't use that language. Why are you here, in CLC; just to complain?

I'm here to understand why people are deifying C and its crude for-loop
by arguing that black is white:

do i = 1,10 # 'primitive'
for(i=1; i<=10; ++i) # 'advanced'

But then at the same some are saying that:

'for' i 'from' 1 'to' 10 'do'

from Algol68 is advanced (because you can stick 'while' in there?).

It's a fascinating. I guess the answers are more psychological than
otherwise.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

bart <bc@freeuk.com> writes:

On 18/04/2025 19:10, James Kuyper wrote:

On 16.04.2025 13:01, bart wrote:
...

Unlike C's for, which is just a gimmick where you bundle three
potentially unrelated expressions and hope for the best.

If all you can do is "hope for the best", you're doing it wrong. It's
your job to ensure that they are not arbitrary unrelated expressions,
but correctly related expressions, and that's no different from your
responsibility for all of the other expressions that make up your
program.

If you find that problematic, you shouldn't be programming in

any language, but certainly not in C.

I see it didn't take you long to get to the personal insult. What is it
with this group?

It's not an insult, it is a simple fact.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)