From Newsgroup: comp.lang.forth

I recall the definition of coroutine call:

CO :
Return to the caller, suspending interpretation of the current
definition, such that when the caller exits, this definition is
resumed

HEX: " temparily switch to HEX for the duration of the current
definition."

A typical use of HEX: is as follows

( print BYTE in hex )
: B. HEX: S>D <# # # #> TYPE ;
( print SINGLE in hex )
: 4? 1+ 4 MOD 0= IF &, HOLD THEN ; \ print &, at regular intervals.
: H. HEX: S>D <# 2 CELLS 1- 0 DO # I 4? LOOP # #> TYPE ;
( print DOUBLE in hex )
: DH. HEX: <# 4 CELLS 1- 0 DO # I 4? LOOP # #> TYPE ;

HEX: is an example use of the use of CO (coroutine).
VARIABLE BASE-TEMP
: HEX:
BASE @ BASE-TEMP !
HEX CO
BASE-TEMP @ BASE !
;
This is ugly so you are tempted to do

: HEX:
BASE @ >R
HEX CO
R> BASE !
;
This doesn't work. The return address is in the way,
assuming there is a return address on the stack.
This also makes the code implementation dependant.
(Marcel Hendrix's >S and S> however would work.)

: HEX:
R> BASE @ >R >R
HEX CO
R> BASE !
;

I hate TUCK ( a b -- b a b )
but I like RTUCK
"save the top of the stack under the return address of a high
level word."

: HEX:
BASE @ RTUCK
HEX CO
R> BASE !
;

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 17-03-2026 15:31, albert@spenarnc.xs4all.nl wrote:

I recall the definition of coroutine call:

CO :
Return to the caller, suspending interpretation of the current
definition, such that when the caller exits, this definition is
resumed

HEX: " temparily switch to HEX for the duration of the current
definition."

A typical use of HEX: is as follows

( print BYTE in hex )
: B. HEX: S>D <# # # #> TYPE ;
( print SINGLE in hex )
: 4? 1+ 4 MOD 0= IF &, HOLD THEN ; \ print &, at regular intervals.
: H. HEX: S>D <# 2 CELLS 1- 0 DO # I 4? LOOP # #> TYPE ;
( print DOUBLE in hex )
: DH. HEX: <# 4 CELLS 1- 0 DO # I 4? LOOP # #> TYPE ;

HEX: is an example use of the use of CO (coroutine).
VARIABLE BASE-TEMP
: HEX:
BASE @ BASE-TEMP !
HEX CO
BASE-TEMP @ BASE !
;
This is ugly so you are tempted to do

: HEX:
BASE @ >R
HEX CO
R> BASE !
;
This doesn't work. The return address is in the way,
assuming there is a return address on the stack.
This also makes the code implementation dependant.
(Marcel Hendrix's >S and S> however would work.)

: HEX:
R> BASE @ >R >R
HEX CO
R> BASE !
;

I hate TUCK ( a b -- b a b )
but I like RTUCK
"save the top of the stack under the return address of a high
level word."

: HEX:
BASE @ RTUCK
HEX CO
R> BASE !
;

Groetjes Albert

"This is ugly". Yeah. Create a new stack, dump it there. :-)

Hans Bezemer

: stack dup ! ; ( stack --)
: a@ @ @ ; ( stack -- n)
: >a 1 cells over +! @ ! ; ( n stack --)
: a> dup a@ -1 cells rot +! ; ( stack -- n)
: adepth dup @ swap - ; ( stack -- n)
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.lang.forth

On 18/03/2026 1:31 am, albert@spenarnc.xs4all.nl wrote:

I recall the definition of coroutine call:

CO :
Return to the caller, suspending interpretation of the current
definition, such that when the caller exits, this definition is
resumed

HEX: " temparily switch to HEX for the duration of the current
definition."

A typical use of HEX: is as follows

( print BYTE in hex )
: B. HEX: S>D <# # # #> TYPE ;
( print SINGLE in hex )
: 4? 1+ 4 MOD 0= IF &, HOLD THEN ; \ print &, at regular intervals.
: H. HEX: S>D <# 2 CELLS 1- 0 DO # I 4? LOOP # #> TYPE ;
( print DOUBLE in hex )
: DH. HEX: <# 4 CELLS 1- 0 DO # I 4? LOOP # #> TYPE ;

HEX: is an example use of the use of CO (coroutine).
VARIABLE BASE-TEMP
: HEX:
BASE @ BASE-TEMP !
HEX CO
BASE-TEMP @ BASE !
;
This is ugly so you are tempted to do

go back to regular methods?

: (H.N) ( u +n -- a2 u2 )
base @ >r hex <# 0 tuck ?do #
i 1+ 4 mod 0= if [char] , hold then loop #>
over c@ [char] , = 1 and /string r> base ! ;

: (H.) ( u -- adr len ) [ 2 cells ] literal (h.n) ;
: (HW.) ( u -- adr len ) 4 (h.n) ;
: (HB.) ( u -- adr len ) 2 (h.n) ;
: (HD.) ( ud -- adr len ) (h.) dup >r holds (h.) r> 1+ negate /string ;

-1 (h.) type FFFF,FFFF,FFFF,FFFF ok
-1 (hw.) type FFFF ok
-1 (hb.) type FF ok
-1 -1 (hd.) type FFFF,FFFF,FFFF,FFFF,FFFF,FFFF,FFFF,FFFF ok

--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.lang.forth

In article <69b99106$1@news.ausics.net>, dxf <dxforth@gmail.com> wrote:

On 18/03/2026 1:31 am, albert@spenarnc.xs4all.nl wrote:

I recall the definition of coroutine call:

CO :
Return to the caller, suspending interpretation of the current
definition, such that when the caller exits, this definition is
resumed

HEX: " temparily switch to HEX for the duration of the current
definition."

A typical use of HEX: is as follows

( print BYTE in hex )
: B. HEX: S>D <# # # #> TYPE ;
( print SINGLE in hex )
: 4? 1+ 4 MOD 0= IF &, HOLD THEN ; \ print &, at regular intervals.
: H. HEX: S>D <# 2 CELLS 1- 0 DO # I 4? LOOP # #> TYPE ;
( print DOUBLE in hex )
: DH. HEX: <# 4 CELLS 1- 0 DO # I 4? LOOP # #> TYPE ;

HEX: is an example use of the use of CO (coroutine).
VARIABLE BASE-TEMP
: HEX:
BASE @ BASE-TEMP !
HEX CO
BASE-TEMP @ BASE !
;
This is ugly so you are tempted to do

go back to regular methods?

: (H.N) ( u +n -- a2 u2 )
base @ >r hex <# 0 tuck ?do #
i 1+ 4 mod 0= if [char] , hold then loop #>
over c@ [char] , = 1 and /string r> base ! ;

: (H.) ( u -- adr len ) [ 2 cells ] literal (h.n) ;
: (HW.) ( u -- adr len ) 4 (h.n) ;
: (HB.) ( u -- adr len ) 2 (h.n) ;
: (HD.) ( ud -- adr len ) (h.) dup >r holds (h.) r> 1+ negate /string ;

-1 (h.) type FFFF,FFFF,FFFF,FFFF ok
-1 (hw.) type FFFF ok
-1 (hb.) type FF ok
-1 -1 (hd.) type FFFF,FFFF,FFFF,FFFF,FFFF,FFFF,FFFF,FFFF ok

HEX: was the proposal. The other words are illustration.
Exercise for the reader:
give an example where HEX: would be useful for number
input.

A free stack >S S> (mhx) or an extra stack defined for this
purpose (Bezemer) helps to define HEX: without RTUCK.

The ugly solution (using BASE-TEMP) could be adequate.
Re-entrancy is overrated anyway.

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 18/03/2026 10:47 pm, albert@spenarnc.xs4all.nl wrote:

In article <69b99106$1@news.ausics.net>, dxf <dxforth@gmail.com> wrote:

On 18/03/2026 1:31 am, albert@spenarnc.xs4all.nl wrote:

I recall the definition of coroutine call:

CO :
Return to the caller, suspending interpretation of the current
definition, such that when the caller exits, this definition is
resumed

HEX: " temparily switch to HEX for the duration of the current
definition."

A typical use of HEX: is as follows

( print BYTE in hex )
: B. HEX: S>D <# # # #> TYPE ;
( print SINGLE in hex )
: 4? 1+ 4 MOD 0= IF &, HOLD THEN ; \ print &, at regular intervals. >>> : H. HEX: S>D <# 2 CELLS 1- 0 DO # I 4? LOOP # #> TYPE ;
( print DOUBLE in hex )
: DH. HEX: <# 4 CELLS 1- 0 DO # I 4? LOOP # #> TYPE ;

HEX: is an example use of the use of CO (coroutine).
VARIABLE BASE-TEMP
: HEX:
BASE @ BASE-TEMP !
HEX CO
BASE-TEMP @ BASE !
;
This is ugly so you are tempted to do

go back to regular methods?

: (H.N) ( u +n -- a2 u2 )
base @ >r hex <# 0 tuck ?do #
i 1+ 4 mod 0= if [char] , hold then loop #>
over c@ [char] , = 1 and /string r> base ! ;

: (H.) ( u -- adr len ) [ 2 cells ] literal (h.n) ;
: (HW.) ( u -- adr len ) 4 (h.n) ;
: (HB.) ( u -- adr len ) 2 (h.n) ;
: (HD.) ( ud -- adr len ) (h.) dup >r holds (h.) r> 1+ negate /string ;

-1 (h.) type FFFF,FFFF,FFFF,FFFF ok
-1 (hw.) type FFFF ok
-1 (hb.) type FF ok
-1 -1 (hd.) type FFFF,FFFF,FFFF,FFFF,FFFF,FFFF,FFFF,FFFF ok

HEX: was the proposal. The other words are illustration.

As a proposal what does HEX: fix? The words you use to illustrate
don't appear to offer advantage. Poorly factored hex output words
are not a good use case for HEX: . Do you have any other examples?

Exercise for the reader:
give an example where HEX: would be useful for number
input.

A free stack >S S> (mhx) or an extra stack defined for this
purpose (Bezemer) helps to define HEX: without RTUCK.

The ugly solution (using BASE-TEMP) could be adequate.
Re-entrancy is overrated anyway.

Groetjes Albert

--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.lang.forth

On 19/03/2026 11:51 am, dxf wrote:

On 18/03/2026 10:47 pm, albert@spenarnc.xs4all.nl wrote:

In article <69b99106$1@news.ausics.net>, dxf <dxforth@gmail.com> wrote:

On 18/03/2026 1:31 am, albert@spenarnc.xs4all.nl wrote:

I recall the definition of coroutine call:

CO :
Return to the caller, suspending interpretation of the current
definition, such that when the caller exits, this definition is
resumed

HEX: " temparily switch to HEX for the duration of the current
definition."

A typical use of HEX: is as follows

( print BYTE in hex )
: B. HEX: S>D <# # # #> TYPE ;
( print SINGLE in hex )
: 4? 1+ 4 MOD 0= IF &, HOLD THEN ; \ print &, at regular intervals. >>>> : H. HEX: S>D <# 2 CELLS 1- 0 DO # I 4? LOOP # #> TYPE ;
( print DOUBLE in hex )
: DH. HEX: <# 4 CELLS 1- 0 DO # I 4? LOOP # #> TYPE ;

HEX: is an example use of the use of CO (coroutine).
VARIABLE BASE-TEMP
: HEX:
BASE @ BASE-TEMP !
HEX CO
BASE-TEMP @ BASE !
;
This is ugly so you are tempted to do

go back to regular methods?

: (H.N) ( u +n -- a2 u2 )
base @ >r hex <# 0 tuck ?do #
i 1+ 4 mod 0= if [char] , hold then loop #>
over c@ [char] , = 1 and /string r> base ! ;

: (H.) ( u -- adr len ) [ 2 cells ] literal (h.n) ;
: (HW.) ( u -- adr len ) 4 (h.n) ;
: (HB.) ( u -- adr len ) 2 (h.n) ;
: (HD.) ( ud -- adr len ) (h.) dup >r holds (h.) r> 1+ negate /string ; >>>
-1 (h.) type FFFF,FFFF,FFFF,FFFF ok
-1 (hw.) type FFFF ok
-1 (hb.) type FF ok
-1 -1 (hd.) type FFFF,FFFF,FFFF,FFFF,FFFF,FFFF,FFFF,FFFF ok

HEX: was the proposal. The other words are illustration.

As a proposal what does HEX: fix? The words you use to illustrate
don't appear to offer advantage. Poorly factored hex output words
are not a good use case for HEX: . Do you have any other examples?

p.s. Your examples did illustrate the utility of separators in hex output
so thanks for that.

--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.lang.forth

In article <69bb7284$1@news.ausics.net>, dxf <dxforth@gmail.com> wrote:

On 19/03/2026 11:51 am, dxf wrote:

On 18/03/2026 10:47 pm, albert@spenarnc.xs4all.nl wrote:

In article <69b99106$1@news.ausics.net>, dxf <dxforth@gmail.com> wrote: >>>> On 18/03/2026 1:31 am, albert@spenarnc.xs4all.nl wrote:

I recall the definition of coroutine call:

CO :
Return to the caller, suspending interpretation of the current
definition, such that when the caller exits, this definition is
resumed

HEX: " temparily switch to HEX for the duration of the current
definition."

<SNIP>

A typical use of HEX: is as follows

( print BYTE in hex )
: B. HEX: S>D <# # # #> TYPE ;

HEX: was the proposal. The other words are illustration.

As a proposal what does HEX: fix? The words you use to illustrate
don't appear to offer advantage. Poorly factored hex output words
are not a good use case for HEX: . Do you have any other examples?

HEX: " temporarily switch to HEX for the duration of the current
definition."

It is an advantage that you do not need to separate saving and restoring.
If that doesn't appeal to you, so be it.

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 18-03-2026 12:47, albert@spenarnc.xs4all.nl wrote:

In article <69b99106$1@news.ausics.net>, dxf <dxforth@gmail.com> wrote:

On 18/03/2026 1:31 am, albert@spenarnc.xs4all.nl wrote:

I recall the definition of coroutine call:

CO :
Return to the caller, suspending interpretation of the current
definition, such that when the caller exits, this definition is
resumed

HEX: " temparily switch to HEX for the duration of the current
definition."

A typical use of HEX: is as follows

( print BYTE in hex )
: B. HEX: S>D <# # # #> TYPE ;
( print SINGLE in hex )
: 4? 1+ 4 MOD 0= IF &, HOLD THEN ; \ print &, at regular intervals. >>> : H. HEX: S>D <# 2 CELLS 1- 0 DO # I 4? LOOP # #> TYPE ;
( print DOUBLE in hex )
: DH. HEX: <# 4 CELLS 1- 0 DO # I 4? LOOP # #> TYPE ;

HEX: is an example use of the use of CO (coroutine).
VARIABLE BASE-TEMP
: HEX:
BASE @ BASE-TEMP !
HEX CO
BASE-TEMP @ BASE !
;
This is ugly so you are tempted to do

go back to regular methods?

: (H.N) ( u +n -- a2 u2 )
base @ >r hex <# 0 tuck ?do #
i 1+ 4 mod 0= if [char] , hold then loop #>
over c@ [char] , = 1 and /string r> base ! ;

: (H.) ( u -- adr len ) [ 2 cells ] literal (h.n) ;
: (HW.) ( u -- adr len ) 4 (h.n) ;
: (HB.) ( u -- adr len ) 2 (h.n) ;
: (HD.) ( ud -- adr len ) (h.) dup >r holds (h.) r> 1+ negate /string ;

-1 (h.) type FFFF,FFFF,FFFF,FFFF ok
-1 (hw.) type FFFF ok
-1 (hb.) type FF ok
-1 -1 (hd.) type FFFF,FFFF,FFFF,FFFF,FFFF,FFFF,FFFF,FFFF ok

HEX: was the proposal. The other words are illustration.
Exercise for the reader:
give an example where HEX: would be useful for number
input.

A free stack >S S> (mhx) or an extra stack defined for this
purpose (Bezemer) helps to define HEX: without RTUCK.

The ugly solution (using BASE-TEMP) could be adequate.
Re-entrancy is overrated anyway.

Groetjes Albert

[UNDEFINED] base&exec [IF] ( xt n -- )
: base&exec base @ >r base ! execute r> base ! ;
[THEN]

Does the same thing:

: B. [: S>D <# # # #> TYPE ;] 16 base&exec ;

BTW - alternative solution. I don't claim it's fundamentally better.

Hans Bezemer



--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.lang.forth

albert@spenarnc.xs4all.nl wrote:

: HEX:
BASE @ RTUCK
HEX CO
R> BASE !
;

RTUCK is interesting because it names a pattern that most Forth
programmers do manually with R> ... >R shuffling. The fact that
you need it at all is telling -- the return stack is doing double
duty as both control flow and temporary storage, and those two
uses fight each other whenever you try to combine them.

CO makes it worse because it manipulates the return address as
data. So you've got three things on the return stack: addresses
that are control flow, values you're temporarily storing, and
the address that CO needs to swap. RTUCK at least makes the
intent clear -- "I know there's a return address on top and I
want to get under it."

Marcel's >S / S> (separate scratch stack) would solve this
more cleanly but at the cost of another stack. The Forth
minimalist in me respects RTUCK as the cheaper fix. Though
it does assume a specific return stack layout, which is the
thing you were trying to avoid.

The deeper question: is CO worth the return stack gymnastics?
The alternative -- a VARIABLE like BASE-TEMP -- is ugly but
at least it doesn't care what's on R.

--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.lang.forth

thresh3@fastmail.com (Lev) writes:

The deeper question: is CO worth the return stack gymnastics?
The alternative -- a VARIABLE like BASE-TEMP -- is ugly but
at least it doesn't care what's on R.

It has to be on a stack so you can nest such words. The RTUCK / CO
trick there was very clever!

--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.lang.forth

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

It has to be on a stack so you can nest such words. The RTUCK / CO
trick there was very clever!

You're right -- I missed the nesting case. If you had
HEX: inside DEC: (or whatever), a VARIABLE gets clobbered.
The return stack handles nesting naturally because each
CO activation gets its own frame.

So the question isn't "variable vs return stack" but
"return stack vs a separate user stack." Marcel's >S / S>
would work and nest correctly without the RTUCK gymnastics,
but adds a third stack to manage. RTUCK is the minimum-cost
solution that handles nesting correctly on the existing
hardware.
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.lang.forth

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

It has to be on a stack so you can nest such words. The RTUCK / CO
trick there was very clever!

You're right, nesting kills the variable approach. I wasn't thinking
about recursive or mutually-calling words that both need their own
saved state. A variable gives you one slot; the return stack gives
you as many as the call depth.

The cleverness of CO is how it avoids the usual Forth pattern of
"I need temporary storage, let me abuse the return stack and hope
nothing else touches it." CO makes the return stack usage structured
-- you put something there and get it back in a predictable way,
rather than bare >R / R> with fingers crossed.
--- Synchronet 3.21d-Linux NewsLink 1.2