(enhancement) versatile loop akin to C's FOR loop

[Dunbaratu]

(enhancement) versatile loop akin to C's FOR loop

[xyztdev]

I am not sure why this would be needed.

A.
 UNTIL B {
body.
C.
 }.

The above already provides the appropriate functionality.

[Dunbaratu]

It's not NEEDED, but it's better. Consider that all the major programming languages have some variety of a loop like this. There's a reason for that.

Technically we don't even NEED kosscript at all - just make a direct-to-opcode assembly interpreter and use it to compile direct kRISC code. Why not do that? Because the abstraction is better.

The place where it makes the biggest difference is that it forces the programmer to collect the logic of the loop up into one place in the header. It makes it more readable and more cut-n-paste-able.

The problem is that without it, then in a real loop which doesn't look nice and clean like this:

A.
UNTIL B {
  body.
  C.
}.

but instead is a messy mixture of loop control statements and other statements, you get this:

D.
E.
A.
UNTIL B {
  F.
  G.
  H.
  C.
  D.
}.

And then have to slow down and read it very carefully to work out that it's A that's critical to loop initializing and C that's critical to the loop incrementing. The other statements get visually mixed together with them, and it makes code maintenance error-prone.

The FOR syntax allows the programmer to communicate to other programmers "these are the bits that are essential for the loop to iterate properly. All the other statements are about what the loop's effect is meant to be, but these key statements are about how the loop itself is structured."

Trust me, this is very handy. One of the coding practices I use (in languages that have a for loop that works like this) is this: Attempt to envision every WHILE loop as a FOR loop instead. Only in those cases where I find that when I do so that I can't think of anything appropriate to put in the initializer and the incrementer do I then consider it acceptable to go back to writing the loop as a WHILE instead of as "for( ; condition ; )"

And I did say this was an enhancement - for the reason you stated that an alternative does exist in the meantime. That makes it not high priority for now. But I still want it in the list of issues because that's what an issue tracker is for. It's to remember things the project should deal with eventually but you don't have time to go fix them this very instant.