From Newsgroup: comp.lang.forth

[email protected] 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, [email protected] wrote:

In article <10p6h8l$163pl$[email protected]>,
Krishna Myneni <[email protected]> wrote:

On 3/14/26 09:13, [email protected] wrote:

In article <[email protected]>,

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, [email protected] wrote:

In article <[email protected]>,

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$[email protected]>,
Krishna Myneni <[email protected]> wrote:

On 3/15/26 13:07, [email protected] wrote:

In article <10p6h8l$163pl$[email protected]>,
Krishna Myneni <[email protected]> wrote:

On 3/14/26 09:13, [email protected] wrote:

In article <[email protected]>,

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, [email protected] wrote:

In article <10p7fni$1hb3l$[email protected]>,
Krishna Myneni <[email protected]> wrote:

On 3/15/26 13:07, [email protected] wrote:

In article <10p6h8l$163pl$[email protected]>,
Krishna Myneni <[email protected]> wrote:

On 3/14/26 09:13, [email protected] wrote:

In article <[email protected]>,

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, [email protected] wrote:

In article <[email protected]>,

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, [email protected] wrote:

In article <10p7fni$1hb3l$[email protected]>,
Krishna Myneni <[email protected]> wrote:

On 3/15/26 13:07, [email protected] wrote:

In article <10p6h8l$163pl$[email protected]>,
Krishna Myneni <[email protected]> wrote:

On 3/14/26 09:13, [email protected] wrote:

In article <[email protected]>,

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, [email protected] wrote:

In article <10p7fni$1hb3l$[email protected]>,
Krishna Myneni  <[email protected]> wrote:

On 3/15/26 13:07, [email protected] wrote:

In article <10p6h8l$163pl$[email protected]>,
Krishna Myneni  <[email protected]> wrote:

On 3/14/26 09:13, [email protected] wrote:

In article <[email protected]>,

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, [email protected] wrote:

In article <10p6h8l$163pl$[email protected]>,
Krishna Myneni <[email protected]> wrote:

On 3/14/26 09:13, [email protected] wrote:

In article <[email protected]>,

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, [email protected] wrote:

In article <[email protected]>,

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, [email protected] wrote:

In article <[email protected]>,

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 <[email protected]> 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$[email protected]>,
Gerry Jackson <[email protected]> wrote:

On 15/03/2026 18:07, [email protected] wrote:

In article <10p6h8l$163pl$[email protected]>,
Krishna Myneni <[email protected]> wrote:

On 3/14/26 09:13, [email protected] wrote:

In article <[email protected]>,

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$[email protected]>,
Krishna Myneni <[email protected]> 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, [email protected] wrote:

In article <10p991u$23uka$[email protected]>,
Krishna Myneni <[email protected]> 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, [email protected] wrote:

In article <10p991u$23uka$[email protected]>,
Krishna Myneni  <[email protected]> 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