From Newsgroup: comp.lang.forth

In article <e24234142613878bbe4431dd36315ffa@www.novabbs.com>,
mhx <mhx@iae.nl> wrote:

This specific version of XCHG causes an implicit LOCK on the bus and
will
execute slower than (probably) expected. (For those readers that were
getting fancy ideas).

That is interesting. Slower than pushing two things on the stack than popping two?

Groetjes Albert
--
Temu exploits Christians: (Disclaimer, only 10 apostles)
Last Supper Acrylic Suncatcher - 15Cm Round Stained Glass- Style Wall
Art For Home, Office And Garden Decor - Perfect For Windows, Bars,
And Gifts For Friends Family And Colleagues.
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.forth

On 9/01/2025 9:50 am, dxf wrote:

On 9/01/2025 5:11 am, Hans Bezemer wrote:

On 08-01-2025 17:27, albert@spenarnc.xs4all.nl wrote:

( my CO variant, using the return address)

: LOCAL R> SWAP DUP >R @ >R EXECUTE R> R> ! ;

VARIABLE A
VARIABLE B

\ I'm paranoid :)

8 a !
7 b !

: divide
    A LOCAL
    B LOCAL
    B ! A !  A @ B @ /
    . CR
;

15 3 divide a ? b ?
\ it doesn't mean they're not out to get you

Wow! This works! Can't say how solid it is.. but still!

Alas not portable.
...

More portable

: (lx) >R ;

: LOCAL R> SWAP DUP >R @ >R (lx) R> R> ! ;

VARIABLE A
VARIABLE B

8 A !
7 B !

: divide ( a b -- )
A LOCAL
B LOCAL
B ! A ! A @ B @ /
. CR
;

15 3 divide A ? B ?
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.forth

In article <9747ef2be5ee93d6a4f0c89352a38cec72624609@i2pn2.org>,
dxf <dxforth@gmail.com> wrote:

On 9/01/2025 9:50 am, dxf wrote:

On 9/01/2025 5:11 am, Hans Bezemer wrote:

On 08-01-2025 17:27, albert@spenarnc.xs4all.nl wrote:

( my CO variant, using the return address)

: LOCAL R> SWAP DUP >R @ >R EXECUTE R> R> ! ;

VARIABLE A
VARIABLE B

\ I'm paranoid :)

8 a !
7 b !

: divide
    A LOCAL
    B LOCAL
    B ! A !  A @ B @ /
    . CR
;

15 3 divide a ? b ?
\ it doesn't mean they're not out to get you

Wow! This works! Can't say how solid it is.. but still!

Alas not portable.
...

Definitely not portable.

R EXECUTE doesn't work for ciforth.

There is no guarantee that a saved interpreter pointer on the
stack is an execution token.

More portable

: (lx) >R ;

: LOCAL R> SWAP DUP >R @ >R (lx) R> R> ! ;

VARIABLE A
VARIABLE B

8 A !
7 B !

: divide ( a b -- )
A LOCAL
B LOCAL
B ! A ! A @ B @ /
. CR
;

15 3 divide A ? B ?

Good catch!
This is an implementation for CO and it works e.g. on ciforth.
But why a different name, CO or ;: as per Chuck Moore.
: CO >R ;
: ;: >R ;
If I use the word (lx) for a decorator, the name makes absolutely no sense.

It is less efficient than a machine code implementation, but it doesn't
rely on information on register use in the interpret machine. This implementation has a good chance to work an a majority of implementations.

Groetjes Albert
--
Temu exploits Christians: (Disclaimer, only 10 apostles)
Last Supper Acrylic Suncatcher - 15Cm Round Stained Glass- Style Wall
Art For Home, Office And Garden Decor - Perfect For Windows, Bars,
And Gifts For Friends Family And Colleagues.
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.forth

On 9/01/2025 10:59 pm, albert@spenarnc.xs4all.nl wrote:

In article <9747ef2be5ee93d6a4f0c89352a38cec72624609@i2pn2.org>,
dxf <dxforth@gmail.com> wrote:

On 9/01/2025 9:50 am, dxf wrote:

On 9/01/2025 5:11 am, Hans Bezemer wrote:

On 08-01-2025 17:27, albert@spenarnc.xs4all.nl wrote:

( my CO variant, using the return address)

: LOCAL R> SWAP DUP >R @ >R EXECUTE R> R> ! ;

VARIABLE A
VARIABLE B

\ I'm paranoid :)

8 a !
7 b !

: divide
    A LOCAL
    B LOCAL
    B ! A !  A @ B @ /
    . CR
;

15 3 divide a ? b ?
\ it doesn't mean they're not out to get you

Wow! This works! Can't say how solid it is.. but still!

Alas not portable.
...

Definitely not portable.

R EXECUTE doesn't work for ciforth.

There is no guarantee that a saved interpreter pointer on the
stack is an execution token.

More portable

: (lx) >R ;

: LOCAL R> SWAP DUP >R @ >R (lx) R> R> ! ;

VARIABLE A
VARIABLE B

8 A !
7 B !

: divide ( a b -- )
A LOCAL
B LOCAL
B ! A ! A @ B @ /
. CR
;

15 3 divide A ? B ?

Good catch!
This is an implementation for CO and it works e.g. on ciforth.
But why a different name, CO or ;: as per Chuck Moore.
: CO >R ;
: ;: >R ;
If I use the word (lx) for a decorator, the name makes absolutely no sense.

I didn't realize I was implementing CO. Now I know what it does.
;: seems a good name. It was also the name of DOES> predecessor but I could never find any details.

It is less efficient than a machine code implementation, but it doesn't
rely on information on register use in the interpret machine. This implementation has a good chance to work an a majority of implementations.

Groetjes Albert

--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.forth

dxf <dxforth@gmail.com> wrote:

On 9/01/2025 9:50 am, dxf wrote:

More portable

: (lx) >R ;

BacForth

: ENTER >R ; \ call word whose address is on the data stack
--
me
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.forth

On 09-01-2025 13:42, dxf wrote:

There is no guarantee that a saved interpreter pointer on the
stack is an execution token.

Nope - in ANS-Forth it is listed as:

nest-sys; definition calls; implementation dependent

So - that's obvious. But in 4tH it works out. And defining it as >R
works out as well. BTW, I've tested the thing - and it holds up.

I got my work cut out for a next episode! On co-routines! ;-)

Hans Bezemer

BTW, I've heard there are implementations where nest-sys aren't even on
the return stack. The standard seems to confirm this:

return stack: A stack that _MAY_BE_ used for program execution nesting, do-loop execution, temporary storage, and other purposes.

.. and sorry to spoil the fun, but what we're doing here is illegal anyways:

"A program shall _NOT_ access values on the return stack (using R@, R>,
2R@ or 2R>) that it _DID_NOT_ place there using >R or 2>R;"

In other words: your mileage may (be) very, very illegal.

Hans Bezemer

--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.forth

albert@spenarnc.xs4all.nl writes:

R EXECUTE doesn't work for ciforth.

There is no guarantee that a saved interpreter pointer on the
stack is an execution token.

In development Gforth, if you use the xt of a colon definition as a
return address, you get the same effect as EXECUTE. E.g.

: colon-execute >r ;

1 ' . colon-execute \ prints "1"

I have recently had a puzzling bug syndrome in the following word
(buggy version shown):

: reverse-sections-execute ( xt -- )
>r sections $@ cell mem-do
j i @ section-execute
loop ;

[: current-section @ cr h. ;] reverse-sections-execute

The output is:

$7FF5F428F000
$7FF5F3F1A000
$7FF5F3F3B000
$7FF5E5BFD000
$7FF5E5DFE040
$7FF5F4298000
$7FF5E5DFE040 ok

The last line should not be output. What happens is that the xt
passed to REVERSE-SECTIONS-EXECUTE is pushed on the return stack, and
I then forgot to drop it. But instead of that resulting in a crash
(as you would get in Gforth up to around 2020), with the new xt
implementation the ; at the end COLON-EXECUTEs the xt. And because
the xt is a colon definition, this calls the xt again.

xt=pfa has it's advantages, but here a disadvantage showed up.

- 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 2023 proceedings: http://www.euroforth.org/ef23/papers/
EuroForth 2024 proceedings: http://www.euroforth.org/ef24/papers/
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.forth

On 10/01/2025 3:15 am, Hans Bezemer wrote:

On 09-01-2025 13:42, dxf wrote:

There is no guarantee that a saved interpreter pointer on the
stack is an execution token.

Albert said that. He's referring to the use of EXECUTE. What surprised me
is half the forths on my desktop worked (though not DX-Forth).

Nope - in ANS-Forth it is listed as:

nest-sys; definition calls; implementation dependent

So - that's obvious. But in 4tH it works out. And defining it as >R works out as well. BTW, I've tested the thing - and it holds up.

I got my work cut out for a next episode! On co-routines! ;-)

Great. While I've seen co-routines mentioned, examples were rare so I
tended to ignore it.

Hans Bezemer

BTW, I've heard there are implementations where nest-sys aren't even on the return stack. The standard seems to confirm this:

return stack:  A stack that _MAY_BE_ used for program execution nesting, do-loop execution, temporary storage, and other purposes.

.. and sorry to spoil the fun, but what we're doing here is illegal anyways:

"A program shall _NOT_ access values on the return stack (using R@, R>, 2R@ or 2R>) that it _DID_NOT_ place there using >R or 2>R;"

In other words: your mileage may (be) very, very illegal.

The >R dependency is on what was (and perhaps still is) 'common practice'.
I was unsure how it would fare but all the popular forths seem to work.
If ANS-FORTH has issued one too many 'Thou shalt not's and in doing so has excluded itself then that's too bad.

--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.forth

In article <nnd$0a3352ed$2c40f494@296559c013ec38eb>,
<albert@spenarnc.xs4all.nl> wrote:

In article <nnd$75b7a2a4$616fdd6b@4f60b314ce95c9b9>,
Hans Bezemer <the.beez.speaks@gmail.com> wrote:

<SNIP>

https://www.youtube.com/watch?v=Y7cax2fDS84

I was impressed with the Behringer solution.
(I didn't care about the politically correct solution.)

====================================
: local{ R> SWAP DUP >R @ >R >R ;
: }global R> R> R> ! >R ;
=================

But I can do you one better.
Remember the word ;: from colorforth. That is actually a coroutine call.
I call it CO. (Present in ciforth since the year 00)

An example of its use is the following:
:NONAME .S ; ' LIST decorated
decorated is not the point. The noname decorates LIST with
the anonymous function, so that the stack is printed, before LIST.
Now we go one step further:
:NONAME .S CO ." AFTER " .S ; ' LIST decorated

Or
:NONAME .S ;: ." AFTER " .S ; ' LIST decorated

The noname decorates LIST with the anonymous function, so that the
stack is printed, before, but now noname is suspended, LIST is
executed as a coroutine, and afterword the stack is printed once more.

With CO the example become
---------------------------------------
: LOCAL R> SWAP DUP >R @ >R >R CO R> R> ! ;

VARIABLE A
VARIABLE B

: divide
A LOCAL
B LOCAL
B ! A ! A @ B @ /
. CR
;

15 3 divide
---------------------------------------

Suppose we adopt Chuck Moore's name

: LOCAL R> SWAP DUP >R @ >R >R ;: R> R> ! ;

This looks even better.

Groetjes Albert

--
Temu exploits Christians: (Disclaimer, only 10 apostles)
Last Supper Acrylic Suncatcher - 15Cm Round Stained Glass- Style Wall
Art For Home, Office And Garden Decor - Perfect For Windows, Bars,
And Gifts For Friends Family And Colleagues.
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.forth

In article <nnd$44fc771d$089c856c@db10b46852f85b89>,
Hans Bezemer <the.beez.speaks@gmail.com> wrote:

On 09-01-2025 13:42, dxf wrote:

There is no guarantee that a saved interpreter pointer on the
stack is an execution token.

Nope - in ANS-Forth it is listed as:

nest-sys; definition calls; implementation dependent

So - that's obvious. But in 4tH it works out. And defining it as >R
works out as well. BTW, I've tested the thing - and it holds up.

I got my work cut out for a next episode! On co-routines! ;-)

Hans Bezemer

BTW, I've heard there are implementations where nest-sys aren't even on
the return stack. The standard seems to confirm this:

return stack: A stack that _MAY_BE_ used for program execution nesting, >do-loop execution, temporary storage, and other purposes.

.. and sorry to spoil the fun, but what we're doing here is illegal anyways:

"A program shall _NOT_ access values on the return stack (using R@, R>,
2R@ or 2R>) that it _DID_NOT_ place there using >R or 2>R;"

In other words: your mileage may (be) very, very illegal.

The use of CO / ;: can't be illegal. Its implementation may not be
portable, that is another matter.
There is no reference to the return stack in the glossary of CO.

========================
CO

STACKEFFECT:

DESCRIPTION: []

Return to the caller, suspending interpretation of the current
definition, such that when the caller exits, this definition is
resumed. The return stack must not be engaged, such as between >R and

, or DO and LOOP .

GLOSSARY INDEX

SEE ALSO: CONTROL EXIT
========================
Merely a warning that the ciforth implementation doesn't work well with certainly manipulations of the return stack.

The strict forbidden of nested definitions is non-sensical,
I allow nested definitions in ciforth with an extension.
: aap { : add + ; ] 1 2 add 3 4 add * ;
The program is non-standard, but if this extension is loaded the Forth
is still conforming.

Hans Bezemer

Groetjes Albert
--
Temu exploits Christians: (Disclaimer, only 10 apostles)
Last Supper Acrylic Suncatcher - 15Cm Round Stained Glass- Style Wall
Art For Home, Office And Garden Decor - Perfect For Windows, Bars,
And Gifts For Friends Family And Colleagues.
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.forth

On 10-01-2025 00:54, dxf wrote:

The >R dependency is on what was (and perhaps still is) 'common practice'.
I was unsure how it would fare but all the popular forths seem to work.
If ANS-FORTH has issued one too many 'Thou shalt not's and in doing so has excluded itself then that's too bad.

Oh, you won't find me on the side of "the standard". As a matter of
fact, 4tH allows a lot of things that the standard doesn't allow and
vice versa. But I think it is a useful tool when deciding what SHOULD be portable or SHOULDN'T be portable.

In general, I'm all for adopting "common practice" (I'm not going to
list all my exceptions). In this case - why not?

1. It's very hard to enforce (unless you flag all RS items - ugly - or separate the call stack);
2. It's useful to create e.g. co-routines;
3. I don't recommend the practice, though. It's hard to wrap your head
around and in 4tH it may clash with the tail call optimizer. But since
4tH is completely sandboxed, you can't do much damage. If you (attempt
to) jump outside the box, the program is halted.

Hans Bezemer


--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.forth

On 10-01-2025 11:53, albert@spenarnc.xs4all.nl wrote:

Suppose we adopt Chuck Moore's name

: LOCAL R> SWAP DUP >R @ >R >R ;: R> R> ! ;

This looks even better.

I chose >YIELD, but I think it as elegant as ;THEN - it signifies "The definition is ending here, but continues after this". It's a LOT better
than CO, if I may be so frank.

I'll fix it today.

Hans Bezemer

--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.forth

dxf <dxforth@gmail.com> wrote:

Great. While I've seen co-routines mentioned, examples were rare so I
tended to ignore it.

-- A closed paren defined as an immediate co-routine can be used at
-- compile time to divide a word into two parts.
-- At run-time the word's first part executes then performs co-routine
-- and somewhere down the input ')' performs co-routine to return control
-- back to the the word's second part.
-- : foo( first part ) second part ;
-- Example:

: foo( ." --> " s0 @ sp! ) begin depth while 5 * . repeat ; OK

foo( 3 2 1 ) --> 5 10 15 OK

I use 'hi( foo bar baz )' to highlight the output of a sequence of
Forth words.
--
me
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.forth

On 11/01/2025 2:50 am, sjack wrote:

dxf <dxforth@gmail.com> wrote:

Great. While I've seen co-routines mentioned, examples were rare so I
tended to ignore it.

-- A closed paren defined as an immediate co-routine can be used at
-- compile time to divide a word into two parts.
-- At run-time the word's first part executes then performs co-routine
-- and somewhere down the input ')' performs co-routine to return control
-- back to the the word's second part.
-- : foo( first part ) second part ;
-- Example:

: foo( ." --> " s0 @ sp! ) begin depth while 5 * . repeat ; OK

foo( 3 2 1 ) --> 5 10 15 OK

I use 'hi( foo bar baz )' to highlight the output of a sequence of
Forth words.

We'll see. I'd like to be able to say 'yes, that's unequivocally
superior to any other solution I might use'. I had that sense with
... R> DROP ... to discard a nest-sys. I may not use it every day in programming but it's present in applications I use nearly every day.

--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.forth

On 9/01/2025 6:13 am, albert@spenarnc.xs4all.nl wrote:

In article <nnd$032b844d$734ee136@776df242e330d1d2>,
Hans Bezemer <the.beez.speaks@gmail.com> wrote:

On 08-01-2025 17:27, albert@spenarnc.xs4all.nl wrote:

I was impressed with the Behringer solution.
(I didn't care about the politically correct solution.)

====================================
: local{ R> SWAP DUP >R @ >R >R ;
: }global R> R> R> ! >R ;
=================

But I can do you one better.
Remember the word ;: from colorforth. That is actually a coroutine call. >>> I call it CO. (Present in ciforth since the year 00)

<snipped>

With CO the example become
---------------------------------------
: LOCAL R> SWAP DUP >R @ >R >R CO R> R> ! ;

VARIABLE A
VARIABLE B

: divide
A LOCAL
B LOCAL
B ! A ! A @ B @ /
. CR
;

15 3 divide
---------------------------------------

This saves a definition and a word-of-code, and a line for every
LOCAL used. Now that is closer to what Chuck Moore would have used.
Remember for Moore CO aka ;: is a standard word.

CO is not standard but it should be, and it is elementary as hell.

Couldn't find the source for either CO or ;: but I got some primitive,
high level form of co-routine in 4tH:

====================================
: yield r> r> swap >r >r ; \ remember that ; compiles EXIT!
aka rdrop grab \ so add a [FORCE] when needed.
====================================

That is the equivalent in high level code.

In assembler, assuming ESI is the interpreter pointer and EBP is the return stack pointer:

CODE CO
XCHG ESI,[EBP]
NEXT,
END-CODE

In assembler the return stack is uncluttered.
...

Just to clarify CO (coroutines) and

: ;: >r ;

are different albeit related beasts. So which one is Moore's?

BTW the latter is equivalent to the 'docol' run-time in most DTC forth.
In my case I'd just need to give the code fragment a name. But is this
latter ;: worth it? Its use seems to be restricted to restoring state
when a word completes. It's not a "coroutine.

Can't say how they measure up. But I guess co-routines is something
Chuck would like - since it's something you can implement quite easily.
So yes, I agree Chuck wouldn't waste that line ;-)

Hans Bezemer

--- Synchronet 3.20c-Linux NewsLink 1.2

From Newsgroup: comp.lang.forth

On 11/03/2025 11:02 am, dxf wrote:

On 9/01/2025 6:13 am, albert@spenarnc.xs4all.nl wrote:

In article <nnd$032b844d$734ee136@776df242e330d1d2>,
Hans Bezemer <the.beez.speaks@gmail.com> wrote:

On 08-01-2025 17:27, albert@spenarnc.xs4all.nl wrote:

...
In assembler, assuming ESI is the interpreter pointer and EBP is the return >> stack pointer:

CODE CO
XCHG ESI,[EBP]
NEXT,
END-CODE

In assembler the return stack is uncluttered.
...

Just to clarify CO (coroutines) and

: ;: >r ;

... So which one is Moore's?

TL;DR From the preceding text apparently it's not - which makes
justifying it somewhat harder.

--- Synchronet 3.20c-Linux NewsLink 1.2

From Newsgroup: comp.lang.forth

In article <775ad5020b3de3cc091ce71506dd0ac5fac16523@i2pn2.org>,
dxf <dxforth@gmail.com> wrote:

On 9/01/2025 6:13 am, albert@spenarnc.xs4all.nl wrote:

In article <nnd$032b844d$734ee136@776df242e330d1d2>,
Hans Bezemer <the.beez.speaks@gmail.com> wrote:

On 08-01-2025 17:27, albert@spenarnc.xs4all.nl wrote:

I was impressed with the Behringer solution.
(I didn't care about the politically correct solution.)

====================================
: local{ R> SWAP DUP >R @ >R >R ;
: }global R> R> R> ! >R ;
=================

But I can do you one better.
Remember the word ;: from colorforth. That is actually a coroutine call. >>>> I call it CO. (Present in ciforth since the year 00)

<snipped>

With CO the example become
---------------------------------------
: LOCAL R> SWAP DUP >R @ >R >R CO R> R> ! ;

VARIABLE A
VARIABLE B

: divide
A LOCAL
B LOCAL
B ! A ! A @ B @ /
. CR
;

15 3 divide
---------------------------------------

This saves a definition and a word-of-code, and a line for every
LOCAL used. Now that is closer to what Chuck Moore would have used.
Remember for Moore CO aka ;: is a standard word.

CO is not standard but it should be, and it is elementary as hell.

Couldn't find the source for either CO or ;: but I got some primitive,
high level form of co-routine in 4tH:

====================================
: yield r> r> swap >r >r ; \ remember that ; compiles EXIT!
aka rdrop grab \ so add a [FORCE] when needed.
====================================

That is the equivalent in high level code.

In assembler, assuming ESI is the interpreter pointer and EBP is the return >> stack pointer:

CODE CO
XCHG ESI,[EBP]
NEXT,
END-CODE

In assembler the return stack is uncluttered.
...

Just to clarify CO (coroutines) and

: ;: >r ;

are different albeit related beasts. So which one is Moore's?

BTW the latter is equivalent to the 'docol' run-time in most DTC forth.
In my case I'd just need to give the code fragment a name. But is this >latter ;: worth it? Its use seems to be restricted to restoring state
when a word completes. It's not a "coroutine.

The code of ;: doesn't clarify anything.
How it can be equivalent to docol which is the label of
common low level code for colon definition is unclear.

The `;: is present in colorforth. I drew (decennia ago) that it is
equivalent to my `CO.
Maybe a colorforth expert can explain what `;: does, if it is not
the same as `CO.

For the record. ;: is Moore. CO is mine.

Can't say how they measure up. But I guess co-routines is something
Chuck would like - since it's something you can implement quite easily.
So yes, I agree Chuck wouldn't waste that line ;-)

Hans Bezemer

--
Temu exploits Christians: (Disclaimer, only 10 apostles)
Last Supper Acrylic Suncatcher - 15Cm Round Stained Glass- Style Wall
Art For Home, Office And Garden Decor - Perfect For Windows, Bars,
And Gifts For Friends Family And Colleagues.
--- Synchronet 3.20c-Linux NewsLink 1.2

From Newsgroup: comp.lang.forth

On 11-03-2025 12:25, albert@spenarnc.xs4all.nl wrote:

The `;: is present in colorforth. I drew (decennia ago) that it is
equivalent to my `CO.
Maybe a colorforth expert can explain what `;: does, if it is not
the same as `CO.

For the record. ;: is Moore. CO is mine.

Actually, when inlining, ;: can be replaced by EXECUTE if and only if
the reference on the Return Stack constitutes a valid xt in the Forth
variant. YIELD (aka CO if I'm not mistaken) can be inlined as R> EXECUTE (under the same conditions).

Since the LOCAL definition has already moved the return address to the
data stack, ;: works.. In an earlier version I moved the return address
back to the return stack and executed YIELD. Which (of course) worked.
So they're not that far apart IMHO.

Hans Bezemer

--- Synchronet 3.20c-Linux NewsLink 1.2

From Newsgroup: comp.lang.forth

On 11/03/2025 10:25 pm, albert@spenarnc.xs4all.nl wrote:

In article <775ad5020b3de3cc091ce71506dd0ac5fac16523@i2pn2.org>,
dxf <dxforth@gmail.com> wrote:

On 9/01/2025 6:13 am, albert@spenarnc.xs4all.nl wrote:

In article <nnd$032b844d$734ee136@776df242e330d1d2>,
Hans Bezemer <the.beez.speaks@gmail.com> wrote:

On 08-01-2025 17:27, albert@spenarnc.xs4all.nl wrote:

I was impressed with the Behringer solution.
(I didn't care about the politically correct solution.)

====================================
: local{ R> SWAP DUP >R @ >R >R ;
: }global R> R> R> ! >R ;
=================

But I can do you one better.
Remember the word ;: from colorforth. That is actually a coroutine call. >>>>> I call it CO. (Present in ciforth since the year 00)

<snipped>

With CO the example become
---------------------------------------
: LOCAL R> SWAP DUP >R @ >R >R CO R> R> ! ;

VARIABLE A
VARIABLE B

: divide
A LOCAL
B LOCAL
B ! A ! A @ B @ /
. CR
;

15 3 divide
---------------------------------------

This saves a definition and a word-of-code, and a line for every
LOCAL used. Now that is closer to what Chuck Moore would have used.
Remember for Moore CO aka ;: is a standard word.

CO is not standard but it should be, and it is elementary as hell.

Couldn't find the source for either CO or ;: but I got some primitive, >>>> high level form of co-routine in 4tH:

====================================
: yield r> r> swap >r >r ; \ remember that ; compiles EXIT! >>>> aka rdrop grab \ so add a [FORCE] when needed. >>>> ====================================

That is the equivalent in high level code.

In assembler, assuming ESI is the interpreter pointer and EBP is the return >>> stack pointer:

CODE CO
XCHG ESI,[EBP]
NEXT,
END-CODE

In assembler the return stack is uncluttered.
...

Just to clarify CO (coroutines) and

: ;: >r ;

are different albeit related beasts. So which one is Moore's?

BTW the latter is equivalent to the 'docol' run-time in most DTC forth.
In my case I'd just need to give the code fragment a name. But is this
latter ;: worth it? Its use seems to be restricted to restoring state
when a word completes. It's not a "coroutine.

The code of ;: doesn't clarify anything.
How it can be equivalent to docol which is the label of
common low level code for colon definition is unclear.
...

Code equivalence is nothing new. It's for sake of clarity that Fig-forth defined both I and R@ despite them sharing the same code. Forth-83 made
the mistake of repurposing NOT because one could use 0= instead. I don't
wish to make the opposite mistake ... adding a word to the kernel I may
never use.

--- Synchronet 3.20c-Linux NewsLink 1.2

From Newsgroup: comp.lang.forth

On 12/03/2025 8:14 am, Hans Bezemer wrote:

...
Since the LOCAL definition has already moved the return address to the data stack, ;: works.. In an earlier version I moved the return address back to the return stack and executed YIELD. Which (of course) worked. So they're not that far apart IMHO.

But of equal value? As you say YIELD can be made to do ;:

--- Synchronet 3.20c-Linux NewsLink 1.2

From Newsgroup: comp.lang.forth

In article <858080e0b3faa16a4b9ba24e3b34e12a555494b4@i2pn2.org>,
dxf <dxforth@gmail.com> wrote:

On 12/03/2025 8:14 am, Hans Bezemer wrote:

...
Since the LOCAL definition has already moved the return address to

the data stack, ;: works.. In an earlier version I moved the return
address back to the return stack and executed YIELD. Which (of course)
worked. So they're not that far apart IMHO.

But of equal value? As you say YIELD can be made to do ;:

This discussion is typical of Forth. A specification of a word
is essential, then I can implement it.
I quarrel about the meaning of ;: , and you casually mention
"do ;:" as if everybody knows what this is supposed to mean.

This is the specification of CO .
Note how the stack effect is ( -- ) .
For most Forthers this is a apparently a sufficient specification.

"
CO

STACKEFFECT:

DESCRIPTION: []

Return to the caller, suspending interpretation of the current
definition, such that when the caller exits, this definition is
resumed. The return stack must not be engaged, such as between >R and
R> , or DO and LOOP .

SEE ALSO: CONTROL EXIT
"

Groetjes Albert
I
--
Temu exploits Christians: (Disclaimer, only 10 apostles)
Last Supper Acrylic Suncatcher - 15Cm Round Stained Glass- Style Wall
Art For Home, Office And Garden Decor - Perfect For Windows, Bars,
And Gifts For Friends Family And Colleagues.
--- Synchronet 3.20c-Linux NewsLink 1.2

From Newsgroup: comp.lang.forth

On 12-03-2025 11:29, albert@spenarnc.xs4all.nl wrote:

In article <858080e0b3faa16a4b9ba24e3b34e12a555494b4@i2pn2.org>,
dxf <dxforth@gmail.com> wrote:

On 12/03/2025 8:14 am, Hans Bezemer wrote:

...

This discussion is typical of Forth. A specification of a word
is essential, then I can implement it.
I quarrel about the meaning of ;: , and you casually mention
"do ;:" as if everybody knows what this is supposed to mean.

This is the specification of CO .
Note how the stack effect is ( -- ) .
For most Forthers this is a apparently a sufficient specification.

Oh, it clarifies everything!

If we assume ;: to be "EXECUTE" and YIELD to be "R> EXECUTE" then ;: can
be coded as ">R YIELD" and YIELD (aka CO) as "R> ;:".

And I can assure you that works.. No matter which definition you apply
to those words - either inlined or high level.

I think that definitely proves the two words are intimately related ;-)

Hans Bezemer

--- Synchronet 3.20c-Linux NewsLink 1.2

From Newsgroup: comp.lang.forth

In article <nnd$3977f8e0$309bbbfa@b7c8c77c999f35b5>,
Hans Bezemer <the.beez.speaks@gmail.com> wrote:

On 12-03-2025 11:29, albert@spenarnc.xs4all.nl wrote:

In article <858080e0b3faa16a4b9ba24e3b34e12a555494b4@i2pn2.org>,
dxf <dxforth@gmail.com> wrote:

On 12/03/2025 8:14 am, Hans Bezemer wrote:

...

This discussion is typical of Forth. A specification of a word
is essential, then I can implement it.
I quarrel about the meaning of ;: , and you casually mention
"do ;:" as if everybody knows what this is supposed to mean.

This is the specification of CO .
Note how the stack effect is ( -- ) .
For most Forthers this is a apparently a sufficient specification.

Oh, it clarifies everything!

You mean that "stack effect is ( -- )" clarifies everything?
You must be sarcastic.

This was an invitation to show a specification of ;; in the same vein.

If we assume ;: to be "EXECUTE" and YIELD to be "R> EXECUTE" then ;: can
be coded as ">R YIELD" and YIELD (aka CO) as "R> ;:".

So
: ;: >R YIELD ; \ Insert POSTPONE as appropriate
: YIELD R> ;; ; \ Insert POSTPONE as appropriate

Very illuminating.

You seem to imply that CO and YIELD are the same.
That doesn't help me one bit to understand ;: .
"
: ;: >R YIELD ;
"
is an accidental implementation that almost certainly doesn't work
on gforth or ciforth.
There are two problems with it:
1. Unbalanced return stack
2. YIELD is not defined.

And I can assure you that works.. No matter which definition you apply
to those words - either inlined or high level.

I think that definitely proves the two words are intimately related ;-)

Hans Bezemer

--
Temu exploits Christians: (Disclaimer, only 10 apostles)
Last Supper Acrylic Suncatcher - 15Cm Round Stained Glass- Style Wall
Art For Home, Office And Garden Decor - Perfect For Windows, Bars,
And Gifts For Friends Family And Colleagues.
--- Synchronet 3.20c-Linux NewsLink 1.2

From Newsgroup: comp.lang.forth

On 12-03-2025 13:51, albert@spenarnc.xs4all.nl wrote:

Oh, it clarifies everything!

You mean that "stack effect is ( -- )" clarifies everything?
You must be sarcastic.

Neither - I was referring to another quote. I forgot which one, but I
can look it up if you wish.

This was an invitation to show a specification of ;; in the same vein.

I'm not good at hints. Ask my wife.

You seem to imply that CO and YIELD are the same.

"Intimately related" does not equal "the same". But IMHO they're
definitely in the same ball park.

Hans Bezemer

--- Synchronet 3.20c-Linux NewsLink 1.2

From Newsgroup: comp.lang.forth

On 12/03/2025 9:29 pm, albert@spenarnc.xs4all.nl wrote:

In article <858080e0b3faa16a4b9ba24e3b34e12a555494b4@i2pn2.org>,
dxf <dxforth@gmail.com> wrote:

On 12/03/2025 8:14 am, Hans Bezemer wrote:

...
Since the LOCAL definition has already moved the return address to

the data stack, ;: works.. In an earlier version I moved the return
address back to the return stack and executed YIELD. Which (of course)
worked. So they're not that far apart IMHO.

But of equal value? As you say YIELD can be made to do ;:

This discussion is typical of Forth. A specification of a word
is essential, then I can implement it.
I quarrel about the meaning of ;: , and you casually mention
"do ;:" as if everybody knows what this is supposed to mean.

This is the specification of CO .
Note how the stack effect is ( -- ) .
For most Forthers this is a apparently a sufficient specification.

"
CO

STACKEFFECT:

DESCRIPTION: []

Return to the caller, suspending interpretation of the current
definition, such that when the caller exits, this definition is
resumed. The return stack must not be engaged, such as between >R and
R> , or DO and LOOP .

It seems a digression to formally specify something you previously
commented on and whose implementation worked on all popular forths.
But to borrow yours, the definition would go something like:

;: ( nest-sys -- )

Return to the caller specified by nest-sys, suspending [etc etc]

--- Synchronet 3.20c-Linux NewsLink 1.2

From Newsgroup: comp.lang.forth

On 13-03-2025 00:04, dxf wrote:

On 12/03/2025 9:29 pm, albert@spenarnc.xs4all.nl wrote:

In article <858080e0b3faa16a4b9ba24e3b34e12a555494b4@i2pn2.org>,
dxf <dxforth@gmail.com> wrote:

On 12/03/2025 8:14 am, Hans Bezemer wrote:

...
Since the LOCAL definition has already moved the return address to

the data stack, ;: works.. In an earlier version I moved the return
address back to the return stack and executed YIELD. Which (of course) >> worked. So they're not that far apart IMHO.

But of equal value? As you say YIELD can be made to do ;:

This discussion is typical of Forth. A specification of a word
is essential, then I can implement it.
I quarrel about the meaning of ;: , and you casually mention
"do ;:" as if everybody knows what this is supposed to mean.

This is the specification of CO .
Note how the stack effect is ( -- ) .
For most Forthers this is a apparently a sufficient specification.

"
CO

STACKEFFECT:

DESCRIPTION: []

Return to the caller, suspending interpretation of the current
definition, such that when the caller exits, this definition is
resumed. The return stack must not be engaged, such as between >R and
R> , or DO and LOOP .

It seems a digression to formally specify something you previously
commented on and whose implementation worked on all popular forths.
But to borrow yours, the definition would go something like:

;: ( nest-sys -- )

Return to the caller specified by nest-sys, suspending [etc etc]

I tend to agree with both of you. Albert-wise, yes, if there is no
formal specification it's hard to identify - or not to identify. AKA -
it isn't the same or it isn't.

IMHO, we've been far too comfortable with the fact that when we call a
word, we create a nest-sys on the Return stack, e.g. (from the ANS-Forth standard):

6.1.1370 EXECUTE
CORE

( i*x xt -- j*x )

Remove xt from the stack and perform the semantics identified by it.
Aren't we missing anything? Like:

( R: -- nest-sys)

Call me stupid, but I have had trouble wrapping my head around the
inlined and word definitions of YIELD - and why they worked identically
(at least on 4tH):

inline: R> EXECUTE
word: : YIELD R> R> SWAP >R >R ;

Or ;: for that matter:

inline: EXECUTE
word: : ;: >R ;

And unless we express the definitions of CO and YIELD formally in these
terms (defining and specifying return stack effects), we shall never
agree whether they're the same or not. And that is where I agree with DXF..

When I abstract both ;: and YIELD, I'd say they're "identical" -
*except* ;: takes its nest-sys|xt from the data stack, while YIELD gets
its net-sys from the return stack.

Ok, roast me.. ;-)

Hans Bezemer
--- Synchronet 3.20c-Linux NewsLink 1.2

From Newsgroup: comp.lang.forth

In article <207e91b417e7d59b64b9289a51ca824c6d26bd6d@i2pn2.org>,
dxf <dxforth@gmail.com> wrote:

On 12/03/2025 9:29 pm, albert@spenarnc.xs4all.nl wrote:

In article <858080e0b3faa16a4b9ba24e3b34e12a555494b4@i2pn2.org>,
dxf <dxforth@gmail.com> wrote:

On 12/03/2025 8:14 am, Hans Bezemer wrote:

...
Since the LOCAL definition has already moved the return address to

the data stack, ;: works.. In an earlier version I moved the return
address back to the return stack and executed YIELD. Which (of course) >> worked. So they're not that far apart IMHO.

But of equal value? As you say YIELD can be made to do ;:

This discussion is typical of Forth. A specification of a word
is essential, then I can implement it.
I quarrel about the meaning of ;: , and you casually mention
"do ;:" as if everybody knows what this is supposed to mean.

This is the specification of CO .
Note how the stack effect is ( -- ) .
For most Forthers this is a apparently a sufficient specification.

"
CO

STACKEFFECT:

DESCRIPTION: []

Return to the caller, suspending interpretation of the current
definition, such that when the caller exits, this definition is
resumed. The return stack must not be engaged, such as between >R and
R> , or DO and LOOP .

It seems a digression to formally specify something you previously
commented on and whose implementation worked on all popular forths.

I beg your pardon? `CO is a kernel word in my Forth. So it is mandatory
that it is formally specified, lest ciforth is worthless.

I started with the opinion that `;: and 'CO are the same.
You contend this. It falls to you to specify ';: as different for
`CO.

But to borrow yours, the definition would go something like:

;: ( nest-sys -- )

Return to the caller specified by nest-sys, suspending [etc etc]

"Something like"?
Honestly this is worthless. 'nest-sys' is utterly vague.
etc etc ?

If you wish me to take you seriously, formulate a proposed extension
to the standard that stands a chance of being approved, or at least
stands a chance of being discussed seriously by the likes of Anton
Ertl or Ullrich Hofman.

Groetjes Albert
--
Temu exploits Christians: (Disclaimer, only 10 apostles)
Last Supper Acrylic Suncatcher - 15Cm Round Stained Glass- Style Wall
Art For Home, Office And Garden Decor - Perfect For Windows, Bars,
And Gifts For Friends Family And Colleagues.
--- Synchronet 3.20c-Linux NewsLink 1.2

From Newsgroup: comp.lang.forth

In article <nnd$79fd4336$4f4d860e@b61d0eda99c83c6c>,
Hans Bezemer <the.beez.speaks@gmail.com> wrote:

On 13-03-2025 00:04, dxf wrote:

On 12/03/2025 9:29 pm, albert@spenarnc.xs4all.nl wrote:

In article <858080e0b3faa16a4b9ba24e3b34e12a555494b4@i2pn2.org>,
dxf <dxforth@gmail.com> wrote:

On 12/03/2025 8:14 am, Hans Bezemer wrote:

...
Since the LOCAL definition has already moved the return address to

the data stack, ;: works.. In an earlier version I moved the return >>> address back to the return stack and executed YIELD. Which (of course)
worked. So they're not that far apart IMHO.

But of equal value? As you say YIELD can be made to do ;:

This discussion is typical of Forth. A specification of a word
is essential, then I can implement it.
I quarrel about the meaning of ;: , and you casually mention
"do ;:" as if everybody knows what this is supposed to mean.

This is the specification of CO .
Note how the stack effect is ( -- ) .
For most Forthers this is a apparently a sufficient specification.

"
CO

STACKEFFECT:

DESCRIPTION: []

Return to the caller, suspending interpretation of the current
definition, such that when the caller exits, this definition is
resumed. The return stack must not be engaged, such as between >R and >>> R> , or DO and LOOP .

It seems a digression to formally specify something you previously
commented on and whose implementation worked on all popular forths.
But to borrow yours, the definition would go something like:

;: ( nest-sys -- )

Return to the caller specified by nest-sys, suspending [etc etc]

I tend to agree with both of you. Albert-wise, yes, if there is no
formal specification it's hard to identify - or not to identify. AKA -
it isn't the same or it isn't.

IMHO, we've been far too comfortable with the fact that when we call a
word, we create a nest-sys on the Return stack, e.g. (from the ANS-Forth >standard):

6.1.1370 EXECUTE
CORE

( i*x xt -- j*x )

Remove xt from the stack and perform the semantics identified by it.
Aren't we missing anything? Like:

( R: -- nest-sys)

No! EXECUTE leaves nothing on the return stack. While executing `xt
there my be things on the return stack, but this is no business
of EXECUTE and certainly not of its specification.
Maybe the return stack looks like (in a certain instant)
nest-sys1 112 <address of ORANGUTAN> 113 nest-sys2 nest-sys3
If you worried about this, you don't understand the beautiful
concept of nesting.

Call me stupid, but I have had trouble wrapping my head around the
inlined and word definitions of YIELD - and why they worked identically
(at least on 4tH):

inline: R> EXECUTE
word: : YIELD R> R> SWAP >R >R ;

Or ;: for that matter:

inline: EXECUTE
word: : ;: >R ;

And unless we express the definitions of CO and YIELD formally in these
terms (defining and specifying return stack effects), we shall never
agree whether they're the same or not. And that is where I agree with DXF..

When I abstract both ;: and YIELD, I'd say they're "identical" -
*except* ;: takes its nest-sys|xt from the data stack, while YIELD gets
its net-sys from the return stack.

Ok, roast me.. ;-)

next-sys is basically nothing. The standard specifies that you can
call a word and when it runs to completion you continue where the caller
left of. Naturally there is data stored somewhere,
and that is on the it is given a name, and reside on the return stack.
Or it may be not. On the ARM a return address could reside in a link
registers.
This is the joke of Homeros. A recent discovery was that the Odysee
was not written by Homeros, but by another guy also called Homeros.
(The joke is that the name is the only known thing of the poet.)
You can infer that nest-sys must exist, and that you must keep the
return stack balanced, to not disturb nest-sys. So you are not
entitled to do anything standard with nest-sys.
At most you can do only system dependant things that are documented
with a specific Forth and resulting in non-portable programs.
The standard would be better off ignoring nest-sys.
(A c-standard have no mentioning of a similar word.).
My specification of `CO is perfectly adequate. It may be clear that
there must be manipulation of nest-sys in the implementation, but
that is no concern of the user. Let the implementation take care of this.

Hans Bezemer

--
Temu exploits Christians: (Disclaimer, only 10 apostles)
Last Supper Acrylic Suncatcher - 15Cm Round Stained Glass- Style Wall
Art For Home, Office And Garden Decor - Perfect For Windows, Bars,
And Gifts For Friends Family And Colleagues.
--- Synchronet 3.20c-Linux NewsLink 1.2

From Newsgroup: comp.lang.forth

dxf <dxforth@gmail.com> wrote:

Code equivalence is nothing new. It's for sake of clarity that Fig-forth defined both I and R@ despite them sharing the same code. Forth-83 made

To be a little more correct FigForth v1.0 did indeed define
I and R (not R@) to share same code. My FigForth still does.
I believe R@ comes from one of the standards,e.g. Forth-83
--
me
--- Synchronet 3.20c-Linux NewsLink 1.2

From Newsgroup: comp.lang.forth

On 14/03/2025 1:35 am, sjack wrote:

dxf <dxforth@gmail.com> wrote:

Code equivalence is nothing new. It's for sake of clarity that Fig-forth
defined both I and R@ despite them sharing the same code. Forth-83 made

To be a little more correct FigForth v1.0 did indeed define
I and R (not R@) to share same code. My FigForth still does.
I believe R@ comes from one of the standards,e.g. Forth-83

AFAIK there was no R or R@ prior to FigForth. MicroForth, Kitt Peat Forth, 'Starting Forth' simply used I for that. It's unclear how FigForth came to have R or Forth-79 came to have R@ .

--- Synchronet 3.20c-Linux NewsLink 1.2

From Newsgroup: comp.lang.forth

In article <926bcdb22f5b30036f236dc5351dcb1b124a3f6e@i2pn2.org>,
dxf <dxforth@gmail.com> wrote:

On 14/03/2025 1:35 am, sjack wrote:

dxf <dxforth@gmail.com> wrote:

Code equivalence is nothing new. It's for sake of clarity that Fig-forth >>> defined both I and R@ despite them sharing the same code. Forth-83 made >>>

To be a little more correct FigForth v1.0 did indeed define
I and R (not R@) to share same code. My FigForth still does.
I believe R@ comes from one of the standards,e.g. Forth-83

AFAIK there was no R or R@ prior to FigForth. MicroForth, Kitt Peat Forth, >'Starting Forth' simply used I for that. It's unclear how FigForth came to >have R or Forth-79 came to have R@ .

Because it is a design mistake of a language to give the same name to
two different functionalities, merely because they happen to have the
same behaviour in a certain implementation.

Study the thousands of different constants in Win32Forth.
A lot of them are 2. Why not replace them with TWO?

Groetjes Albert
--
Temu exploits Christians: (Disclaimer, only 10 apostles)
Last Supper Acrylic Suncatcher - 15Cm Round Stained Glass- Style Wall
Art For Home, Office And Garden Decor - Perfect For Windows, Bars,
And Gifts For Friends Family And Colleagues.
--- Synchronet 3.20c-Linux NewsLink 1.2

From Newsgroup: comp.lang.forth

albert@spenarnc.xs4all.nl wrote:

Because it is a design mistake of a language to give the same name to
two different functionalities, merely because they happen to have the
same behaviour in a certain implementation.

A given behavior may play different roles in different contexts. Giving
names to a behavior that fit the roles it plays provides clarity of
intent. For example, COUNT is associated with conversion of a
counted-string. However, its behavior is also well suited in running
along any string, or portion of string, in memory and fetching its
characters. In this latter role using the name C@++ would not give the
false impression of a counted-string being in play.
--
me
--- Synchronet 3.20c-Linux NewsLink 1.2

From Newsgroup: comp.lang.forth

sjack <sjack@dontemail.me> wrote:

More role play:
--
-- 'CO' is a co-processor
--
: foo ." 1FOO " co ." 5BAR " ;
: bat ." 2BAT " co ." 4CAT " ;
cr i. foo bat .( 3boo )

1FOO 2BAT 3boo 4CAT 5BAR

--
-- ')' is also a co-processor
--
: goo( ." GOO " ) ." GU " ;
cr i. goo( foo bat .( 3boo ) )

GOO 1FOO 2BAT 3boo 4CAT 5BAR GU

: rev. begin dup while . repeat drop ;
: rev( 0 ) rev. ;
i. rev( 1 2 3 4 ) --> 4 3 2 1

In FigForth SP! resets data stack. Toad extension XX ,a two tap,
does the same for ease and speed. Recall in old days it was
common to type .. to quickly clear the stack by entering an
invalid word.
--
me

--- Synchronet 3.20c-Linux NewsLink 1.2

From Newsgroup: comp.lang.forth

On 14-03-2025 13:51, albert@spenarnc.xs4all.nl wrote:

Because it is a design mistake of a language to give the same name to
two different functionalities, merely because they happen to have the
same behaviour in a certain implementation.

COUNT? For C@+? Anybody? ;-)

Hans Bezemer

--- Synchronet 3.20c-Linux NewsLink 1.2

From Newsgroup: comp.lang.forth

In article <nnd$195c1faa$7b482483@cd77336ac20a3e59>,
Hans Bezemer <the.beez.speaks@gmail.com> wrote:

On 14-03-2025 13:51, albert@spenarnc.xs4all.nl wrote:

Because it is a design mistake of a language to give the same name to
two different functionalities, merely because they happen to have the
same behaviour in a certain implementation.

COUNT? For C@+? Anybody? ;-)

COUNT should have named $@ . Luckily it isn't, so that I can use $@
for strings that has the count in a cell.
I resist the temptation to abuse $@.
So I do
WANT ALIAS
'$@ ALIAS @+

Hans Bezemer

Groetjes Albert
--
Temu exploits Christians: (Disclaimer, only 10 apostles)
Last Supper Acrylic Suncatcher - 15Cm Round Stained Glass- Style Wall
Art For Home, Office And Garden Decor - Perfect For Windows, Bars,
And Gifts For Friends Family And Colleagues.
--- Synchronet 3.20c-Linux NewsLink 1.2

From Newsgroup: comp.lang.forth

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

On 14-03-2025 13:51, albert@spenarnc.xs4all.nl wrote:

COUNT? For C@+? Anybody? ;-)

here 1 c, 2 c, 3 c, 4 c,
{ 4 0 do count . loop drop }
i. {} --> 1 2 3 4

FigForth COUNT normally operates on a 'byte' counted string but
can also be used to fetch a character and bump address.
--
me
--- Synchronet 3.20c-Linux NewsLink 1.2

From Newsgroup: comp.lang.forth

sjack <sjack@dontemail.me> wrote:

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

On 14-03-2025 13:51, albert@spenarnc.xs4all.nl wrote:

COUNT? For C@+? Anybody? ;-)

here 1 c, 2 c, 3 c, 4 c,
{ 4 0 do count . loop drop }
i. {} --> 1 2 3 4

FigForth COUNT normally operates on a 'byte' counted string but
can also be used to fetch a character and bump address.

And in the context of role play:

here 1 c, 2 c, 3 c, 4 c,
dup { 4 0 do count . loop drop } \ WTF!!! Where's the counted string?
i. {} --> 1 2 3 4

{ 4 0 do c@++ . loop drop } \ Obvious there ain't one here.
i. {} --> 1 2 3 4
--
me

--- Synchronet 3.20c-Linux NewsLink 1.2

From Newsgroup: comp.lang.forth

In article <vr7d97$2h8n5$1@dont-email.me>, sjack <sjack@dontemail.me> wrote: >Hans Bezemer <the.beez.speaks@gmail.com> wrote:

On 14-03-2025 13:51, albert@spenarnc.xs4all.nl wrote:

COUNT? For C@+? Anybody? ;-)

here 1 c, 2 c, 3 c, 4 c,
{ 4 0 do count . loop drop }

lina -n
S[ ] OK here 1 c, 2 c, 3 c,

S[ 4266523 ] OK 'COUNT ALIAS C@+

S[ 4266523 ] OK 3 0 do C@+ . LOOP DROP
1 2 3
S[ ] OK here 1 c, 2 c, 3 c,

S[ 4266523 ] OK 'COUNT ALIAS C@+

S[ 4266523 ] OK 3 0 do C@+ . LOOP DROP
1 2 3

i. {} --> 1 2 3 4

No what is that supposed to mean?

FigForth COUNT normally operates on a 'byte' counted string but
can also be used to fetch a character and bump address.

Professionals finds this objectionable.

me

Groetjes Albert
--
Temu exploits Christians: (Disclaimer, only 10 apostles)
Last Supper Acrylic Suncatcher - 15Cm Round Stained Glass- Style Wall
Art For Home, Office And Garden Decor - Perfect For Windows, Bars,
And Gifts For Friends Family And Colleagues.
--- Synchronet 3.20c-Linux NewsLink 1.2

From Newsgroup: comp.lang.forth

On 17-03-2025 12:31, albert@spenarnc.xs4all.nl wrote:

FigForth COUNT normally operates on a 'byte' counted string but
can also be used to fetch a character and bump address.

Professionals finds this objectionable.

I wholeheartedly agree! IMHO it is SO important to document and show
your intentions as a programmer! E.g. I recently added CLIP as a
counterpart to CHOP (1 /STRING) to make clear (often to my future self)
that it is my INTENTION to remove the right most character from an
addr/count string.

I'm even so extreme in that regard that I use OVER OVER instead of 2DUP
to make clear the values have no connection. I would use 2DUP only for addr/counts of arrays, double numbers, etc.

I know not everybody agrees to the latter point. That's okay. If I ever
port your sources I'll figure it out.. I won't be as hard as COUNT.
Nowadays, I'm even capable of figuring out the use of booleans as number values. ;-)

Hans Bezemer



--- Synchronet 3.20c-Linux NewsLink 1.2

From Newsgroup: comp.lang.forth

albert@spenarnc.xs4all.nl wrote:

i. {} --> 1 2 3 4

No what is that supposed to mean?

Ok, for the record then, Toad test and demo aids:

1) { ... }
Set a marker and compile the code within the braces.

2) {}
Executes the code compiled by { ... } but doesn't perform the marker,
therefore {} can execute the code multiple times if so desired.

The marker can be performed manually by performing {FIN} .
{FIN} is found in other words such as E or RUN1 (they the same)
which follow { ... } to do a one-time execution of the marked code.

Other words execute the code multiple times in a loop and performs
{FIN} when done:
i. RUN
Loops the code until TRUE is returned
i. RUNS
Loops the code n times
i. GRUN
Performs RUN and drops g-string that remained on stack
i. FORALL
Perform {} on all (counted) strings on the data stack
3) i.
Print " --> " .
It serves as a list item mark and also prints an arrow to indicate
the output of the words that follow.

Summary:

i. { ... } E \ run once
i. { ... } RUN1 \ ditto, run once
i. { ... } n RUNS \ run n times
i. { ... } RUN \ run while returned flag is TRUE
i. { ... } GRUN \ perform RUN and drop a remaining g-string
i. { ... } FORALL \ perform {} on each (counted) string on the data stack

Note: g-string is a generic string; it is referenced by address and
count on the data stack (standard Forth strings are g-strings)
--
me
--- Synchronet 3.20c-Linux NewsLink 1.2

From Newsgroup: comp.lang.forth

albert@spenarnc.xs4all.nl wrote:

Professionals finds this objectionable.

I wouldn't know. The burning bush never spoke to me.
I'm obligated to give testimony but it's up to providence what, where
and how seeds are sown or burnt as chaff.
I don't push for it one way or the other. I strive not to preach lest
I become Lermontov's _Prophet_.
--
me

--- Synchronet 3.20c-Linux NewsLink 1.2

From Newsgroup: comp.lang.forth

On 18/03/2025 4:12 am, sjack wrote:

albert@spenarnc.xs4all.nl wrote:

Professionals finds this objectionable.

I wouldn't know. The burning bush never spoke to me.
I'm obligated to give testimony but it's up to providence what, where
and how seeds are sown or burnt as chaff.
I don't push for it one way or the other. I strive not to preach lest
I become Lermontov's _Prophet_.

Someone made the point prophets were either killed or worshipped - and
that this was much the same thing. Be careful what you wish for?



--- Synchronet 3.20c-Linux NewsLink 1.2

From Newsgroup: comp.lang.forth

On 17-03-2025 18:12, sjack wrote:

albert@spenarnc.xs4all.nl wrote:

Professionals finds this objectionable.

I wouldn't know. The burning bush never spoke to me.
I'm obligated to give testimony but it's up to providence what, where
and how seeds are sown or burnt as chaff.
I don't push for it one way or the other. I strive not to preach lest
I become Lermontov's _Prophet_.

"Since the eternal judge gave me the omniscience of a prophet, in the
eyes of people I read pages of malice and vice."

Seems like an accurate description of c.l.f. ..

“Behold: for here’s a case for you! This man was haughty and abrasive:
And though he spoke divinely too, his foolish words were not persuasive."

Seems like all of us when we give our opinion here ;-)

Hans Bezemer


--- Synchronet 3.20c-Linux NewsLink 1.2