From Newsgroup: comp.lang.forth

Hi 4tH-ers!

You know we've been struggling with DO..LOOP since eternity. Chuck
thought he's rather replace the whole shebang with FOR..NEXT.

For years I've largely avoided DO..LOOP where possible, using
BEGIN..REPEAT instead.

But now I've encoded it in a few macros - and it works fine (at first
sight)!

Like DO..LOOP it keeps its parameters on the Return stack, but it allows
WHILE of EXCEPT to add additional conditions. With the parameters on the Return stack, it still requires UNLOOP to exit it, of course.

Also - you feed the parameters like a BASIC FOR..NEXT loop - that is: inclusive. It also does NOT enter the loop when parameters are out of
reach. And you can define a STEP very naturally. In 4tH, you can still
use I and J.

:macro countup 1+ begin over over >r >r < while ;
:macro countdown 1- begin over over >r >r > while ;
:macro step r> + r> repeat rdrop rdrop ;

10 30 countup i . 1 step cr
30 10 countdown i . -1 step cr
10 30 countup i . i 15 < while 1 step cr

This renders:

10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30
30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10
10 11 12 13 14 15

Let me know what you think. I'm adding this to the 4pp repository.

Hans Bezemer
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.lang.forth

Hans Bezemer <the.beez.speaks@gmail.com> writes:

Let me know what you think. I'm adding this to the 4pp repository.

I thought ?DO was supposed to fix the main issues of DO.
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.lang.forth

Paul Rubin <no.email@nospam.invalid> writes:

I thought ?DO was supposed to fix the main issues of DO.

?DO is an improvement over DO in many cases, but I found the resulting
standard counted-loop variants unsatisfying, and have worked on
improved counted-loop constructs over the last three decades, even as
recently as 2024 <2024Jan28.131537@mips.complang.tuwien.ac.at>.

You can read the "Counted Loops" Section in the manual of Gforth's
development version (currently unavailable on the web <https://net2o.de/gforth/>, but hopefully online again soon) and think
about why I introduced the various additional words were introduced.
No other Forth system has picked them up, so maybe other Forth systems
do not consider the standard counted loops as unsatisfying as I do, or
maybe they consider the price in additional words to be too high.

- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: https://forth-standard.org/
EuroForth 2025 proceedings: http://www.euroforth.org/ef25/papers/
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.lang.forth

On 13-03-2026 23:05, Paul Rubin wrote:

Hans Bezemer <the.beez.speaks@gmail.com> writes:

Let me know what you think. I'm adding this to the 4pp repository.

I thought ?DO was supposed to fix the main issues of DO.

Okay, quick overview of developments - I found the names horrible.
Second - the syntax itself didn't translate nicely to ANS-Forth for
reasons I explain later.

So - I thought:

[A] It resembles the BASIC syntax - like: "FOR x = 10 TO 30 STEP 1 :
NEXT x" So why not go all the way? I mean - it's not like FOR..NEXT is standard;
[B] It also fixed the point that you cannot terminate an additional
WHILE the ANS-94 way.

In short - the entire routine has the following advantages:

- It is easier to parse mentally;
- It is consistent for both ascending and descending loops;
- It has all the advantages of ?DO..LOOP + it won't enter faux loops;
- You can add additional WHILE's - no more need for LEAVE;
- Portable, you don't need to meddle with control stacks;
- Lots of Forths allow the continued use of "I" and "J".

So - what does it look like? Just four easy definitions:

: for
postpone 1+ postpone begin postpone over postpone over
postpone >r postpone >r postpone < postpone while ; immediate

: -for
postpone 1- postpone begin postpone over postpone over
postpone >r postpone >r postpone > postpone while ; immediate

: step postpone r> postpone + postpone r> postpone repeat ; immediate
: next postpone rdrop postpone rdrop ; immediate

Examples:

: ex1 10 30 for i . 1 step next cr ; ok
ex1 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30
ok
: ex2 30 10 -for i . -1 step next cr ; ok
ex2 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10
ok
: ex3 10 30 for i . i 15 < while 1 step then next cr ; ok
ex3 10 11 12 13 14 15
ok
: ex4 30 10 for i . 1 step next cr ; ok
ex4
ok

This is the ?DO..LOOP equivalent of "ex4" (*). Try it.

: ex5 10 30 ?do i . loop cr ;

Hans Bezemer

(*) About. I can never remember the proper syntax of descending loops.
Not even for my own compiler. It's all very confusing.





--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.lang.forth

In article <2026Mar14.115416@mips.complang.tuwien.ac.at>,
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:

Paul Rubin <no.email@nospam.invalid> writes:

I thought ?DO was supposed to fix the main issues of DO.

?DO is an improvement over DO in many cases, but I found the resulting >standard counted-loop variants unsatisfying, and have worked on
improved counted-loop constructs over the last three decades, even as >recently as 2024 <2024Jan28.131537@mips.complang.tuwien.ac.at>.

You can read the "Counted Loops" Section in the manual of Gforth's >development version (currently unavailable on the web ><https://net2o.de/gforth/>, but hopefully online again soon) and think
about why I introduced the various additional words were introduced.
No other Forth system has picked them up, so maybe other Forth systems
do not consider the standard counted loops as unsatisfying as I do, or
maybe they consider the price in additional words to be too high.

We have painted ourselves in a corner.

I certainly do find DO unsatisfactory. I don't think it can be settled
unless we define the body as a lambda, an anonymous piece of code
that can be executed repeatedly.
The cute trick that DO can be used to handle signed and unsigned indices
at the same time is holding us back.
\ DO ( i1 i2 xt -- ?? )
1 3 { IX . } DO
1 2 3 OK
3 1 { IX . } DO
OK
The idea about +LOOP is also insane. If you have an increment, that must be defined once and for all.
1 6 2 { IX . } DO[..]
1 3 5 OK
That also fixes decrementing loops:
6 1 -2 { IX . } DO[..]
6 4 2 OK

Note that this construct can be executed or compiled,
in the premise that he distinction between
:NONAME .. ; and [: .. ;]
is also defective.
There is no hope that this can be approved,
because you are actually defining a whole new language.
Merely adding extra words that burdens the memory is not a good
solution.

For now I accept DO DO? for better or for worse.

- anton

Groetjes Albert
--
The Chinese government is satisfied with its military superiority over USA.
The next 5 year plan has as primary goal to advance life expectancy
over 80 years, like Western Europe.
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.lang.forth

On 14-03-2026 11:54, Anton Ertl wrote:

Paul Rubin <no.email@nospam.invalid> writes:

I thought ?DO was supposed to fix the main issues of DO.

?DO is an improvement over DO in many cases, but I found the resulting standard counted-loop variants unsatisfying, and have worked on
improved counted-loop constructs over the last three decades, even as recently as 2024 <2024Jan28.131537@mips.complang.tuwien.ac.at>.

You can read the "Counted Loops" Section in the manual of Gforth's development version (currently unavailable on the web <https://net2o.de/gforth/>, but hopefully online again soon) and think
about why I introduced the various additional words were introduced.
No other Forth system has picked them up, so maybe other Forth systems
do not consider the standard counted loops as unsatisfying as I do, or
maybe they consider the price in additional words to be too high.

- anton

Oh, I've NO ILLUSIONS AT ALL that *ANY* proposal concerning "DO..LOOP"
will *EVER* displace it. It's simple - just too much code that'll be
broken..

However, since I've been eradicating DO..LOOP constructs for years - by replacing them by BEGIN..UNTIL variants I thought - "why not try to make
some template for that". If you know 4tH - I don't have to fix it in the
core. I just have to feed a template to the preprocessor.

An then, late at night, I thought, why not embrace the BASIC syntax.
It's familiar, it's easily readable and does its job just fine. This one
even adds a few functionalities to it.

In essence, the basic trick is it moves the decision to enter the loop
*MUCH* closer to BEGIN. STEP essentially does what Albert suggests - it
just increments the index.

Second, incrementing loops and decrementing loops require different
words - just like Anton suggested.

So in short, I just thought that the combination of all these ideas
would make a nice c.l.f. topic.

.. but I think I solved what I set out to do. ;-)

Hans Bezemer
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.lang.forth

albert@spenarnc.xs4all.nl writes:

We have painted ourselves in a corner.

Speak for yourself. I am actually pretty happy with the current set
of Gforth's counted-loop words.

I certainly do find DO unsatisfactory. I don't think it can be settled
unless we define the body as a lambda, an anonymous piece of code
that can be executed repeatedly.

Gforth has support for (flat) closures, and they can be useful in some
cases, but for counted loops I don't see any benefit from closures
(even the varant with access to outer locals).

Sure, TRAVERSE-WORDLIST is similar in spirit to a counted loop and we
pass an xt to it (so, in Gforth, you can pass a closure to it); an
alternative to that would have been to have a ?DO-WORDLIST and a
LOOP-WORDLIST, or somesuch; the current entry might have been gotten
with I, and LEAVE would leave the loop, making it unnecessary to pass
a flag to indicate this.

The cute trick that DO can be used to handle signed and unsigned indices
at the same time is holding us back.

Speak for yourself. Gforth has words for signed and for unsigned loop
control parameters:

+DO -[DO -DO
U+DO U-[DO U-DO

Gforth also has

ARRAY>MEM MEM+DO MEM-DO

which factors away the error-prone array handling (especially
beneficial in the MEM-DO case).

The idea about +LOOP is also insane. If you have an increment, that must be >defined once and for all.
1 6 2 { IX . } DO[..]
1 3 5 OK
That also fixes decrementing loops:
6 1 -2 { IX . } DO[..]
6 4 2 OK

That's certainly the idea behind ARRAY>MEM and MEM+DO and MEM-DO, but
they are designed for dealing with arrays. Maybe one day I will come
across a usage that will inspire me to design a more general counted
loop with stride.

- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: https://forth-standard.org/
EuroForth 2025 proceedings: http://www.euroforth.org/ef25/papers/
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.lang.forth

albert@spenarnc.xs4all.nl writes:

I certainly do find DO unsatisfactory. I don't think it can be settled
unless we define the body as a lambda, an anonymous piece of code
that can be executed repeatedly.

I now remember doing something like that in my first Forth program. It
got tedious and I decided after a while that I was trying to force-fit conventions from other languages onto Forth, and that this wasn't proper
Forth style.
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.lang.forth

On 15/03/2026 12:54 am, Hans Bezemer wrote:

...
(*) About. I can never remember the proper syntax of descending loops. Not even for my own compiler. It's all very confusing.

I can surely remember DO LOOP is asymmetric and test if need be.
I'd have trouble remembering the gforth variants and what they did.

FOR NEXT is appealing for small micros that can't afford DO LOOP.
The question is whether there's a form that would satisfy all parties.

--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.lang.forth

In article <877brednoq.fsf@nightsong.com>,
Paul Rubin <no.email@nospam.invalid> wrote:

albert@spenarnc.xs4all.nl writes:

I certainly do find DO unsatisfactory. I don't think it can be settled
unless we define the body as a lambda, an anonymous piece of code
that can be executed repeatedly.

I now remember doing something like that in my first Forth program. It
got tedious and I decided after a while that I was trying to force-fit >conventions from other languages onto Forth, and that this wasn't proper >Forth style.

Did you use the proper starting point?
You must start with a denotation, valid in interpreter and compilation
mode that anonymously present an xt. (No environment imported, just
the behaviour)

I have no problem doing this. Suddenly UNLOOP makes more sense,
because in this context EXIT means "continue with the next
iteration".

Groetjes Albert
--
The Chinese government is satisfied with its military superiority over USA.
The next 5 year plan has as primary goal to advance life expectancy
over 80 years, like Western Europe.
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.lang.forth

In article <2026Mar14.163425@mips.complang.tuwien.ac.at>,
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:

albert@spenarnc.xs4all.nl writes:

We have painted ourselves in a corner.

Speak for yourself. I am actually pretty happy with the current set
of Gforth's counted-loop words.

The truth is independant whether any one person accept it or not.

DO remains me of Patriot missiles. Invented in the cold war era,
fixed and updated, now ineffective.

<SNIP>

- anton

Groetjes Albert
--
The Chinese government is satisfied with its military superiority over USA.
The next 5 year plan has as primary goal to advance life expectancy
over 80 years, like Western Europe.
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.lang.forth

On 3/14/26 09:13, albert@spenarnc.xs4all.nl wrote:

In article <2026Mar14.115416@mips.complang.tuwien.ac.at>,

The idea about +LOOP is also insane. If you have an increment, that must be defined once and for all.

Maybe I misunderstand what you are saying, but +LOOP does not use a
fixed step. It uses whatever is on the stack, so the increment can vary
from iteration to iteration.

--
Krishna

--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.lang.forth

On 3/15/26 09:55, Krishna Myneni wrote:

On 3/14/26 09:13, albert@spenarnc.xs4all.nl wrote:

In article <2026Mar14.115416@mips.complang.tuwien.ac.at>,

The idea about +LOOP is also insane. If you have an increment, that
must be
defined once and for all.

Maybe I misunderstand what you are saying, but +LOOP does not use a
fixed step. It uses whatever is on the stack, so the increment can vary
from iteration to iteration.

Example:

:noname 1000 0 do i . i 1+ +loop ; execute
0 1 3 7 15 31 63 127 255 511 ok

--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.lang.forth

In article <10p6h8l$163pl$1@dont-email.me>,
Krishna Myneni <krishna.myneni@ccreweb.org> wrote:

On 3/14/26 09:13, albert@spenarnc.xs4all.nl wrote:

In article <2026Mar14.115416@mips.complang.tuwien.ac.at>,

The idea about +LOOP is also insane. If you have an increment, that must be >> defined once and for all.

Maybe I misunderstand what you are saying, but +LOOP does not use a
fixed step. It uses whatever is on the stack, so the increment can vary
from iteration to iteration.

Exactly. That is what wrong with it.

--
Krishna

--
The Chinese government is satisfied with its military superiority over USA.
The next 5 year plan has as primary goal to advance life expectancy
over 80 years, like Western Europe.
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.lang.forth

On 15-03-2026 16:01, Krishna Myneni wrote:

On 3/15/26 09:55, Krishna Myneni wrote:

On 3/14/26 09:13, albert@spenarnc.xs4all.nl wrote:

In article <2026Mar14.115416@mips.complang.tuwien.ac.at>,

The idea about +LOOP is also insane. If you have an increment, that
must be
defined once and for all.

Maybe I misunderstand what you are saying, but +LOOP does not use a
fixed step. It uses whatever is on the stack, so the increment can
vary from iteration to iteration.

Example:

:noname 1000 0 do i . i 1+ +loop ; execute
0 1 3 7 15 31 63 127 255 511  ok

No sweat!

: ex 0 999 for i . i 1+ step next ; ok
ex 0 1 3 7 15 31 63 127 255 511 ok

Hans Bezemer
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.lang.forth

albert@spenarnc.xs4all.nl writes:

Did you use the proper starting point?
You must start with a denotation, valid in interpreter and compilation
mode that anonymously present an xt. (No environment imported, just
the behaviour)

I think I used named functions, e.g.

: FOO .... whatever ... ;

: BAR ['] FOO 5 TIMES ;

So TIMES took an xt and an execution count.
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.lang.forth

On 3/15/26 13:07, albert@spenarnc.xs4all.nl wrote:

In article <10p6h8l$163pl$1@dont-email.me>,
Krishna Myneni <krishna.myneni@ccreweb.org> wrote:

On 3/14/26 09:13, albert@spenarnc.xs4all.nl wrote:

In article <2026Mar14.115416@mips.complang.tuwien.ac.at>,

The idea about +LOOP is also insane. If you have an increment, that must be >>> defined once and for all.

Maybe I misunderstand what you are saying, but +LOOP does not use a
fixed step. It uses whatever is on the stack, so the increment can vary >>from iteration to iteration.

Exactly. That is what wrong with it.

Just use a constant then. Are you concerned with the present spec's efficiency?

--
KM

--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.lang.forth

On 3/15/26 13:11, Hans Bezemer wrote:

On 15-03-2026 16:01, Krishna Myneni wrote:

On 3/15/26 09:55, Krishna Myneni wrote:

On 3/14/26 09:13, albert@spenarnc.xs4all.nl wrote:

In article <2026Mar14.115416@mips.complang.tuwien.ac.at>,

The idea about +LOOP is also insane. If you have an increment, that
must be
defined once and for all.

Maybe I misunderstand what you are saying, but +LOOP does not use a
fixed step. It uses whatever is on the stack, so the increment can
vary from iteration to iteration.

Example:

:noname 1000 0 do i . i 1+ +loop ; execute
0 1 3 7 15 31 63 127 255 511  ok

No sweat!

: ex 0 999 for i . i 1+ step next ;  ok
ex 0 1 3 7 15 31 63 127 255 511  ok

What does the following do when you substitute FOR ... STEP NEXT for DO
... +LOOP ?

-1 1 rshift constant MAX-INT

MAX-INT DUP 2/ + CONSTANT LIM
MAX-INT 4 / CONSTANT INCR

: ex LIM 0 DO I . CR INCR +LOOP ;

Per my understanding of the standard for +LOOP on 2's complement 64-bit systems, it should output the following.

0
2305843009213693951
4611686018427387902
6917529027641081853
9223372036854775804
-6917529027641081861
-4611686018427387910
ok

--
Krishna

P.S. I had to fix the behavior of +LOOP in kForth-64 recently, to pass
Gerry Jackson's coreplustest suite of tests for +LOOP.


--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.lang.forth

In article <10p7fni$1hb3l$1@dont-email.me>,
Krishna Myneni <krishna.myneni@ccreweb.org> wrote:

On 3/15/26 13:07, albert@spenarnc.xs4all.nl wrote:

In article <10p6h8l$163pl$1@dont-email.me>,
Krishna Myneni <krishna.myneni@ccreweb.org> wrote:

On 3/14/26 09:13, albert@spenarnc.xs4all.nl wrote:

In article <2026Mar14.115416@mips.complang.tuwien.ac.at>,

The idea about +LOOP is also insane. If you have an increment, that must be
defined once and for all.

Maybe I misunderstand what you are saying, but +LOOP does not use a
fixed step. It uses whatever is on the stack, so the increment can vary >>>from iteration to iteration.

Exactly. That is what wrong with it.

Just use a constant then. Are you concerned with the present spec's >efficiency?

I interpret efficiency as speed of the compiled code.
I don't care about that. I want transparent code, that
-- if and when you choose to optimise -- does not hinder
optimisation.
My philosophy is, that you only optimise procedures that needs
to be fast, not as a global flag for a compiler, or a
permanent burden that has to be present (and errorfree)
for the compiler.

KM

Groetjes Albert
--
The Chinese government is satisfied with its military superiority over USA.
The next 5 year plan has as primary goal to advance life expectancy
over 80 years, like Western Europe.
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.lang.forth

On 3/16/26 06:26, albert@spenarnc.xs4all.nl wrote:

In article <10p7fni$1hb3l$1@dont-email.me>,
Krishna Myneni <krishna.myneni@ccreweb.org> wrote:

On 3/15/26 13:07, albert@spenarnc.xs4all.nl wrote:

In article <10p6h8l$163pl$1@dont-email.me>,
Krishna Myneni <krishna.myneni@ccreweb.org> wrote:

On 3/14/26 09:13, albert@spenarnc.xs4all.nl wrote:

In article <2026Mar14.115416@mips.complang.tuwien.ac.at>,

The idea about +LOOP is also insane. If you have an increment, that must be
defined once and for all.

Maybe I misunderstand what you are saying, but +LOOP does not use a
fixed step. It uses whatever is on the stack, so the increment can vary >>> >from iteration to iteration.

Exactly. That is what wrong with it.

Just use a constant then. Are you concerned with the present spec's
efficiency?

I interpret efficiency as speed of the compiled code.
I don't care about that. I want transparent code, that
-- if and when you choose to optimise -- does not hinder
optimisation.
My philosophy is, that you only optimise procedures that needs
to be fast, not as a global flag for a compiler, or a
permanent burden that has to be present (and errorfree)
for the compiler.

+LOOP is transparent once you view it properly as stepping through the unsigned numbers and wrapping around, either in positive increments
which increase the unsigned number or in negative increments which
decrease the unsigned number e.g.

---
MAX-UINT
:
:
MIN-INT
MAX-INT
:
:
0
---

--
KM

Groetjes Albert

--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.lang.forth

On 16-03-2026 01:36, Krishna Myneni wrote:

On 3/15/26 13:11, Hans Bezemer wrote:

On 15-03-2026 16:01, Krishna Myneni wrote:

On 3/15/26 09:55, Krishna Myneni wrote:

On 3/14/26 09:13, albert@spenarnc.xs4all.nl wrote:

In article <2026Mar14.115416@mips.complang.tuwien.ac.at>,

The idea about +LOOP is also insane. If you have an increment, that >>>>> must be
defined once and for all.

Maybe I misunderstand what you are saying, but +LOOP does not use a
fixed step. It uses whatever is on the stack, so the increment can
vary from iteration to iteration.

Example:

:noname 1000 0 do i . i 1+ +loop ; execute
0 1 3 7 15 31 63 127 255 511  ok

No sweat!

: ex 0 999 for i . i 1+ step next ;  ok
ex 0 1 3 7 15 31 63 127 255 511  ok

What does the following do when you substitute FOR ... STEP NEXT for DO
... +LOOP ?

-1 1 rshift constant MAX-INT

MAX-INT DUP 2/ + CONSTANT LIM
MAX-INT 4 /      CONSTANT INCR

: ex LIM 0 DO I . CR INCR +LOOP ;

Per my understanding of the standard for +LOOP on 2's complement 64-bit systems, it should output the following.

0
2305843009213693951
4611686018427387902
6917529027641081853
9223372036854775804
-6917529027641081861
-4611686018427387910
 ok

--
Krishna

P.S. I had to fix the behavior of +LOOP in kForth-64 recently, to pass
Gerry Jackson's coreplustest suite of tests for +LOOP.

for compiling
postpone 1+ postpone begin postpone over postpone over compiling
postpone >r postpone >r postpone < postpone while ; immediate
ok
: -for compiling
postpone 1- postpone begin postpone over postpone over compiling
postpone >r postpone >r postpone > postpone while ; immediate ok
: step postpone r> postpone + postpone r> postpone repeat ; immediate ok
: next postpone rdrop postpone rdrop ; immediate
ok
-1 1 rshift constant MAX-INT ok
ok
MAX-INT DUP 2/ + CONSTANT LIM ok
MAX-INT 4 / CONSTANT INCR ok
ok
: ex 0 LIM 1- FOR I . CR INCR STEP NEXT ; ok
ex ok


It does what it is supposed to do: quit the loop, since
-4611686018427387906 is smaller than 0. But what exactly do you want to
prove here? That it does a signed compare? Doesn't that tell you exactly
what one has to fix here - if you INSIST on having an unsigned
comparison (which, IMHO was one of the worst decisions Forth-83 EVER
made). I mean - how often have you used such a loop in general programming?

: for compiling
postpone 1+ postpone begin postpone over postpone over compiling
postpone >r postpone >r postpone < postpone while ; immediate
ok
: ufor compiling
postpone 1+ postpone begin postpone over postpone over compiling
postpone >r postpone >r postpone u< postpone while ; immediate ok
ok
: -for compiling
postpone 1- postpone begin postpone over postpone over compiling
postpone >r postpone >r postpone > postpone while ; immediate
ok
: step postpone r> postpone + postpone r> postpone repeat ; immediate
: next postpone rdrop postpone rdrop ; immediate
ok
ok
-1 1 rshift constant MAX-INT
ok
MAX-INT DUP 2/ + CONSTANT LIM
MAX-INT 4 / CONSTANT INCR
ok
: ex 0 LIM 1- UFOR I . CR INCR STEP NEXT ;
ok
ex 0
2305843009213693951
4611686018427387902
6917529027641081853
9223372036854775804
-6917529027641081861
-4611686018427387910
ok


QED. If you can have a -FOR, why not a UFOR? Duh!

Hans Bezemer



--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.lang.forth

On 16-03-2026 12:26, albert@spenarnc.xs4all.nl wrote:

In article <10p7fni$1hb3l$1@dont-email.me>,
Krishna Myneni <krishna.myneni@ccreweb.org> wrote:

On 3/15/26 13:07, albert@spenarnc.xs4all.nl wrote:

In article <10p6h8l$163pl$1@dont-email.me>,
Krishna Myneni <krishna.myneni@ccreweb.org> wrote:

On 3/14/26 09:13, albert@spenarnc.xs4all.nl wrote:

In article <2026Mar14.115416@mips.complang.tuwien.ac.at>,

The idea about +LOOP is also insane. If you have an increment, that must be
defined once and for all.

Maybe I misunderstand what you are saying, but +LOOP does not use a
fixed step. It uses whatever is on the stack, so the increment can vary >>> >from iteration to iteration.

Exactly. That is what wrong with it.

Just use a constant then. Are you concerned with the present spec's
efficiency?

I interpret efficiency as speed of the compiled code.
I don't care about that. I want transparent code, that
-- if and when you choose to optimise -- does not hinder
optimisation.
My philosophy is, that you only optimise procedures that needs
to be fast, not as a global flag for a compiler, or a
permanent burden that has to be present (and errorfree)
for the compiler.

KM

Groetjes Albert

Those newbies don't understand that LESS code often means FASTER code.
Take that to it's logical conclusion and the fastest code means NO CODE
AT ALL.

Code has so many more qualities than that. If that weren't true, Python wouldn't have a shadow of a chance.

Hans
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.lang.forth

On 16-03-2026 14:20, Krishna Myneni wrote:

On 3/16/26 06:26, albert@spenarnc.xs4all.nl wrote:

In article <10p7fni$1hb3l$1@dont-email.me>,
Krishna Myneni  <krishna.myneni@ccreweb.org> wrote:

On 3/15/26 13:07, albert@spenarnc.xs4all.nl wrote:

In article <10p6h8l$163pl$1@dont-email.me>,
Krishna Myneni  <krishna.myneni@ccreweb.org> wrote:

On 3/14/26 09:13, albert@spenarnc.xs4all.nl wrote:

In article <2026Mar14.115416@mips.complang.tuwien.ac.at>,

The idea about +LOOP is also insane. If you have an increment,
that must be
defined once and for all.

Maybe I misunderstand what you are saying, but +LOOP does not use a
fixed step. It uses whatever is on the stack, so the increment can
vary
from iteration to iteration.

Exactly. That is what wrong with it.

Just use a constant then. Are you concerned with the present spec's
efficiency?

I interpret efficiency as speed of the compiled code.
I don't care about that. I want transparent code, that
-- if and when you choose to optimise -- does not hinder
optimisation.
My philosophy is, that you only optimise procedures that needs
to be fast, not as a global flag for a compiler, or a
permanent burden that has to be present (and errorfree)
for the compiler.

+LOOP is transparent once you view it properly as stepping through the unsigned numbers and wrapping around, either in positive increments
which increase the unsigned number or in negative increments which
decrease the unsigned number e.g.

---
MAX-UINT
:
:
MIN-INT
MAX-INT
:
:
0
---

--
KM

Groetjes Albert

Everything is transparent once you are able to follow the stream of consciousness by a deranged mind. But I'm not a guy like that - and
neither is my audience, I suppose.

The error of DO was NOT to evaluate the parameters given - and
consequently the error of +LOOP was it did *more* than just update the
index.

The error of LEAVE was to just equalize the index and the limit - and
not jump. The error of the next iteration of LEAVE was it actually *did*
jump.

The error of ?DO was not to take the direction of the loop into
consideration - so only equal limits and indexes fell through. And - it
did jump, so now there were *TWO* things making the same decision. How
messy can you make things.

I can understand the need for an unsigned DO..LOOP in the 16-bit era,
but there is no need for that in the 32-bit era.

One of the huge errors of Forth-83 standard was they caved in to
pressure and made DO..LOOP unsigned. Gee folks, can't you really bake an unsigned BEGIN..REPEAT? Really?

Now this huge accumulation of design errors got us where we are now. And
I'm afraid it's unfixable. There are just too many DO..LOOPs in the
world - even if one just regards my own code. I tend to fix programs
once I've made a change. I've fixed hundreds of programs in my time. But
this one is too daunting for me too.

However, that won't stop me from evaluating better solutions. And maybe
- maybe if I have been able to convince myself, I will upgrade
FOR..STEP..NEXT to another level.

But I'll never defend a lousy construct - my own or someone elses - for
any reason. At best, I'll excuse myself by saying I'm too lazy too fix it.

Hans Bezemer
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.lang.forth

On 15/03/2026 18:07, albert@spenarnc.xs4all.nl wrote:

In article <10p6h8l$163pl$1@dont-email.me>,
Krishna Myneni <krishna.myneni@ccreweb.org> wrote:

On 3/14/26 09:13, albert@spenarnc.xs4all.nl wrote:

In article <2026Mar14.115416@mips.complang.tuwien.ac.at>,

The idea about +LOOP is also insane. If you have an increment, that must be >>> defined once and for all.

Maybe I misunderstand what you are saying, but +LOOP does not use a
fixed step. It uses whatever is on the stack, so the increment can vary >>from iteration to iteration.

Exactly. That is what wrong with it.

Wrong, if varying the increment does what you require it's right.

A trivial example

: fib 1 swap 0 do i . i swap +loop drop ; cr 1000 fib
0 1 1 2 3 5 8 13 21 34 55 89 144 233 377 610 987 ok
--
Gerry
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.lang.forth

On 3/16/26 08:28, Hans Bezemer wrote:

On 16-03-2026 01:36, Krishna Myneni wrote:

On 3/15/26 13:11, Hans Bezemer wrote:

On 15-03-2026 16:01, Krishna Myneni wrote:

On 3/15/26 09:55, Krishna Myneni wrote:

On 3/14/26 09:13, albert@spenarnc.xs4all.nl wrote:

In article <2026Mar14.115416@mips.complang.tuwien.ac.at>,

The idea about +LOOP is also insane. If you have an increment,
that must be
defined once and for all.

Maybe I misunderstand what you are saying, but +LOOP does not use a >>>>> fixed step. It uses whatever is on the stack, so the increment can
vary from iteration to iteration.

Example:

:noname 1000 0 do i . i 1+ +loop ; execute
0 1 3 7 15 31 63 127 255 511  ok

No sweat!

: ex 0 999 for i . i 1+ step next ;  ok
ex 0 1 3 7 15 31 63 127 255 511  ok

What does the following do when you substitute FOR ... STEP NEXT for
DO ... +LOOP ?

-1 1 rshift constant MAX-INT

MAX-INT DUP 2/ + CONSTANT LIM
MAX-INT 4 /      CONSTANT INCR

: ex LIM 0 DO I . CR INCR +LOOP ;

Per my understanding of the standard for +LOOP on 2's complement 64-
bit systems, it should output the following.

0
2305843009213693951
4611686018427387902
6917529027641081853
9223372036854775804
-6917529027641081861
-4611686018427387910
  ok

--
Krishna

P.S. I had to fix the behavior of +LOOP in kForth-64 recently, to pass
Gerry Jackson's coreplustest suite of tests for +LOOP.

 for compiling
  postpone 1+ postpone begin postpone over postpone over compiling
  postpone >r postpone >r postpone <  postpone while ; immediate
  ok
: -for compiling
  postpone 1- postpone begin postpone over postpone over compiling
  postpone >r postpone >r postpone >  postpone while ; immediate  ok
: step  postpone r> postpone + postpone r> postpone repeat ; immediate  ok : next  postpone rdrop postpone rdrop ; immediate
  ok
-1 1 rshift constant MAX-INT  ok
  ok
MAX-INT DUP 2/ + CONSTANT LIM  ok
MAX-INT 4 /      CONSTANT INCR   ok
  ok
: ex 0 LIM 1- FOR I . CR INCR STEP NEXT ;  ok
ex  ok

It does what it is supposed to do: quit the loop, since
-4611686018427387906 is smaller than 0. But what exactly do you want to prove here? That it does a signed compare? Doesn't that tell you exactly what one has to fix here - if you INSIST on having an unsigned
comparison (which, IMHO was one of the worst decisions Forth-83 EVER
made). I mean - how often have you used such a loop in general programming?

: for compiling
  postpone 1+ postpone begin postpone over postpone over compiling
  postpone >r postpone >r postpone <  postpone while ; immediate
    ok
: ufor compiling
  postpone 1+ postpone begin postpone over postpone over compiling
  postpone >r postpone >r postpone u<  postpone while ; immediate  ok
  ok
: -for compiling
  postpone 1- postpone begin postpone over postpone over compiling
  postpone >r postpone >r postpone >  postpone while ; immediate
  ok
: step  postpone r> postpone + postpone r> postpone repeat ; immediate
: next  postpone rdrop postpone rdrop ; immediate
  ok
  ok
-1 1 rshift constant MAX-INT
  ok
MAX-INT DUP 2/ + CONSTANT LIM
MAX-INT 4 /      CONSTANT INCR
  ok
: ex 0 LIM 1- UFOR I . CR INCR STEP NEXT ;
ok
ex 0
2305843009213693951
4611686018427387902
6917529027641081853
9223372036854775804
-6917529027641081861
-4611686018427387910
 ok

QED. If you can have a -FOR, why not a UFOR? Duh!

I don't need six or seven variants of DO ... +LOOP. IMO, it's cleaner
just to understand DO ... +LOOP and use it correctly.

--
KM

--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.lang.forth

On 16-03-2026 16:53, Krishna Myneni wrote:

On 3/16/26 08:28, Hans Bezemer wrote:

On 16-03-2026 01:36, Krishna Myneni wrote:

On 3/15/26 13:11, Hans Bezemer wrote:

On 15-03-2026 16:01, Krishna Myneni wrote:

On 3/15/26 09:55, Krishna Myneni wrote:

On 3/14/26 09:13, albert@spenarnc.xs4all.nl wrote:

In article <2026Mar14.115416@mips.complang.tuwien.ac.at>,

The idea about +LOOP is also insane. If you have an increment,
that must be
defined once and for all.

Maybe I misunderstand what you are saying, but +LOOP does not use >>>>>> a fixed step. It uses whatever is on the stack, so the increment
can vary from iteration to iteration.

Example:

:noname 1000 0 do i . i 1+ +loop ; execute
0 1 3 7 15 31 63 127 255 511  ok

No sweat!

: ex 0 999 for i . i 1+ step next ;  ok
ex 0 1 3 7 15 31 63 127 255 511  ok

What does the following do when you substitute FOR ... STEP NEXT for
DO ... +LOOP ?

-1 1 rshift constant MAX-INT

MAX-INT DUP 2/ + CONSTANT LIM
MAX-INT 4 /      CONSTANT INCR

: ex LIM 0 DO I . CR INCR +LOOP ;

Per my understanding of the standard for +LOOP on 2's complement 64-
bit systems, it should output the following.

0
2305843009213693951
4611686018427387902
6917529027641081853
9223372036854775804
-6917529027641081861
-4611686018427387910
  ok

--
Krishna

P.S. I had to fix the behavior of +LOOP in kForth-64 recently, to
pass Gerry Jackson's coreplustest suite of tests for +LOOP.

  for compiling
   postpone 1+ postpone begin postpone over postpone over compiling
   postpone >r postpone >r postpone <  postpone while ; immediate
   ok
: -for compiling
   postpone 1- postpone begin postpone over postpone over compiling
   postpone >r postpone >r postpone >  postpone while ; immediate  ok
: step  postpone r> postpone + postpone r> postpone repeat ;
immediate  ok
: next  postpone rdrop postpone rdrop ; immediate
   ok
-1 1 rshift constant MAX-INT  ok
   ok
MAX-INT DUP 2/ + CONSTANT LIM  ok
MAX-INT 4 /      CONSTANT INCR   ok
   ok
: ex 0 LIM 1- FOR I . CR INCR STEP NEXT ;  ok
ex  ok


It does what it is supposed to do: quit the loop, since
-4611686018427387906 is smaller than 0. But what exactly do you want
to prove here? That it does a signed compare? Doesn't that tell you
exactly what one has to fix here - if you INSIST on having an unsigned
comparison (which, IMHO was one of the worst decisions Forth-83 EVER
made). I mean - how often have you used such a loop in general
programming?

: for compiling
   postpone 1+ postpone begin postpone over postpone over compiling
   postpone >r postpone >r postpone <  postpone while ; immediate
     ok
: ufor compiling
   postpone 1+ postpone begin postpone over postpone over compiling
   postpone >r postpone >r postpone u<  postpone while ; immediate  ok >>    ok
: -for compiling
   postpone 1- postpone begin postpone over postpone over compiling
   postpone >r postpone >r postpone >  postpone while ; immediate
   ok
: step  postpone r> postpone + postpone r> postpone repeat ; immediate
: next  postpone rdrop postpone rdrop ; immediate
   ok
   ok
-1 1 rshift constant MAX-INT
   ok
MAX-INT DUP 2/ + CONSTANT LIM
MAX-INT 4 /      CONSTANT INCR
   ok
: ex 0 LIM 1- UFOR I . CR INCR STEP NEXT ;
ok
ex 0
2305843009213693951
4611686018427387902
6917529027641081853
9223372036854775804
-6917529027641081861
-4611686018427387910
  ok


QED. If you can have a -FOR, why not a UFOR? Duh!

I don't need six or seven variants of DO ... +LOOP. IMO, it's cleaner
just to understand DO ... +LOOP and use it correctly.

--
KM

Well, Anton seems to differ as well. He made lots of extra DO's to fix
it. And FYI - you never use ?DO - IMHO it is the most useful one, since
it's the only one that skips a LOOP when the loop parameters don't fit.

So - this proliferation of "DO's" has started already - and you embraced it.

Note that unlike your insistence to force an unsigned loop - which I
doubt any Forther will ever encounter in the wild - "FOR" and "-FOR"
would suffice.

Now - how are two variations of "DO" superior to two variations of
"FOR"? Especially when you consider that the unsigned character of "DO"
was in essence a misguided heritage of the 16-bit era?

I mean - how long have I programmed in Forth? And how often did I need
an signed version of "DO"? Never.

First of all, I almost solely use counted loops when there is no "LEAVE" condition. Because it always becomes butt ugly - contrary to
BEGIN..REPEAT loops (especially when REPEAT resolves ALL WHILE's ;-)

Second, the ranges stay well within the range of a signed integer -
especially when you're doing 32- or 64-bit integers.

So - you don't need a whole slew of FOR variants. Two will do quite nicely.

Third, I like intentionality. "-FOR" means I intend to do a decrementing
loop. "FOR" means I'm doing a vanilla incrementing loop. Just like (to
me) "2DUP" means "I'm copying two related stack items" and "OVER OVER"
means "I'm copying two non-related stack items". Like "C@+" means "I'm fetching a byte value - and increment the pointer" and "COUNT" means
"I'm converting a counted string to an addr/count string".

I like to do my future me a service. And he thanks me.

Hans Bezemer
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.lang.forth

In article <nnd$537703e0$23c53c27@a710ea5afc40ee5f>,
Hans Bezemer <the.beez.speaks@gmail.com> wrote:
<SNIP>

I can understand the need for an unsigned DO..LOOP in the 16-bit era,
but there is no need for that in the 32-bit era.

One of the huge errors of Forth-83 standard was they caved in to
pressure and made DO..LOOP unsigned. Gee folks, can't you really bake an >unsigned BEGIN..REPEAT? Really?

I think it is worse than unsigned, it uses a tricky circular stuff, but I
could be mistaken.


Point 5 of my portability chapter:

5. Counting in do loops do not wrap through the boundary between
negative and positive numbers. This is not useful on Forths of 32
bits and higher; for compatibility among ciforths 16 bit ciforths
don't wrap either.

This is one of the reasons that I called my Forth "Close to Iso Forth". Portability is high on my priority list, but this I could not stand.

But I'll never defend a lousy construct - my own or someone elses - for
any reason. At best, I'll excuse myself by saying I'm too lazy too fix it.

P.S.
I wonder if I could rephrase this as :
DO .. LOOP uses signed numbers

Hans Bezemer

Groetjes Albert
--
The Chinese government is satisfied with its military superiority over USA.
The next 5 year plan has as primary goal to advance life expectancy
over 80 years, like Western Europe.
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.lang.forth

In article <10p94st$22cjt$1@dont-email.me>,
Gerry Jackson <do-not-use@swldwa.uk> wrote:

On 15/03/2026 18:07, albert@spenarnc.xs4all.nl wrote:

In article <10p6h8l$163pl$1@dont-email.me>,
Krishna Myneni <krishna.myneni@ccreweb.org> wrote:

On 3/14/26 09:13, albert@spenarnc.xs4all.nl wrote:

In article <2026Mar14.115416@mips.complang.tuwien.ac.at>,

The idea about +LOOP is also insane. If you have an increment, that must be
defined once and for all.

Maybe I misunderstand what you are saying, but +LOOP does not use a
fixed step. It uses whatever is on the stack, so the increment can vary >>>from iteration to iteration.

Exactly. That is what wrong with it.

Wrong, if varying the increment does what you require it's right.

A trivial example

: fib 1 swap 0 do i . i swap +loop drop ; cr 1000 fib
0 1 1 2 3 5 8 13 21 34 55 89 144 233 377 610 987 ok

I am with Bezemer.
The proper construct here is a BEGIN WHILE REPEAT.

--
Gerry

Groetjes Albert
--
The Chinese government is satisfied with its military superiority over USA.
The next 5 year plan has as primary goal to advance life expectancy
over 80 years, like Western Europe.
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.lang.forth

In article <10p991u$23uka$1@dont-email.me>,
Krishna Myneni <krishna.myneni@ccreweb.org> wrote:
<SNIP>

I don't need six or seven variants of DO ... +LOOP. IMO, it's cleaner
just to understand DO ... +LOOP and use it correctly.

You trade memory burden for insight. If you can do it, it
is advantageous. The formule for cos(a+b) is insane.
It you understand exp(i(a+b)) it falls in place.

I don't have a mensa level iq. If you want other people to
understand your programs, that is maybe not the right attitude.
Also if you are pushing eighty, (as I am), you risk that you no
longer understand your own programs.

KM

Groetjes Albert
--
The Chinese government is satisfied with its military superiority over USA.
The next 5 year plan has as primary goal to advance life expectancy
over 80 years, like Western Europe.
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.lang.forth

On 3/16/26 2:25 PM, albert@spenarnc.xs4all.nl wrote:

In article <10p991u$23uka$1@dont-email.me>,
Krishna Myneni <krishna.myneni@ccreweb.org> wrote:
<SNIP>

I don't need six or seven variants of DO ... +LOOP. IMO, it's cleaner
just to understand DO ... +LOOP and use it correctly.

You trade memory burden for insight. If you can do it, it
is advantageous. The formule for cos(a+b) is insane.
It you understand exp(i(a+b)) it falls in place.

I don't have a mensa level iq. If you want other people to
understand your programs, that is maybe not the right attitude.
Also if you are pushing eighty, (as I am), you risk that you no
longer understand your own programs.

Admittedly it took me the better part of two days to figure out the
logic to make +LOOP pass the coreplustest tests. However, most of the difficulty was getting the conceptual picture correct in my head for
what it is intended to do. After that the coding wasn't that hard.

I don't have anything against someone coding a special variant or two of
the stepped loops for signed integers, with different loop iteration
behavior. But, one should be careful about the following

1) they are not replacements for DO ... +LOOP
2) they can also be misused
3) not to proliferate so many types of loops that it becomes a memory burden

--
KM

--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.lang.forth

On 16-03-2026 22:52, Krishna Myneni wrote:

On 3/16/26 2:25 PM, albert@spenarnc.xs4all.nl wrote:

In article <10p991u$23uka$1@dont-email.me>,
Krishna Myneni  <krishna.myneni@ccreweb.org> wrote:
<SNIP>

I don't need six or seven variants of DO ... +LOOP. IMO, it's cleaner
just to understand DO ... +LOOP and use it correctly.

You trade memory burden for insight. If you can do it, it
is advantageous. The formule for cos(a+b) is insane.
It you understand exp(i(a+b)) it falls in place.

I don't have a mensa level iq. If you want other people to
understand your programs, that is maybe not the right attitude.
Also if you are pushing eighty, (as I am), you risk that you no
longer understand your own programs.

Admittedly it took me the better part of two days to figure out the
logic to make +LOOP pass the coreplustest tests. However, most of the difficulty was getting the conceptual picture correct in my head for
what it is intended to do. After that the coding wasn't that hard.

I don't have anything against someone coding a special variant or two of
the stepped loops for signed integers, with different loop iteration behavior. But, one should be careful about the following

1) they are not replacements for DO ... +LOOP
2) they can also be misused
3) not to proliferate so many types of loops that it becomes a memory
burden

--
KM

Ad 1. Replacement in what sense? For legacy use - true, not a
replacement. I never claimed it was;
Ad 2. Like COUNT (as C@+) or CMOVE (as a kind of fill replacement)? I'd
say - join the club!
Ad 3. I'd have no problem coding this in Forth-79 on a Sinclair
Spectrum. So I'm afraid you have to explain that one.

BTW, note that you can use a loop as an offset. Which means that if you
need the higher areas, you can do an offset. Need the lower areas too?
Use a second loop.

Or drop the whole idea and do all the 18446744073709551615 iterations
with BEGIN..UNTIL and take a lunch break ;-)

Hans Bezemer
--- Synchronet 3.21d-Linux NewsLink 1.2