From Newsgroup: comp.lang.forth

On 20/01/2026 08:35, Paul Rubin wrote:

albert@spenarnc.xs4all.nl writes:

If you pass an address a as a tail call is it approximately equal
to coroutines:

No I don't think so. The tail call is just a jump to that address
(changes the program counter). A coroutine jump also has to change the
stack pointer. See the section "Knuth's coroutines" here:

https://www.chiark.greenend.org.uk/~sgtatham/coroutines.html

Some Forths have a CO primitive that I think is similar. There is
something like it on the Greenarrays processor.

Never having looked at coroutines before I tried implementing the
examples in the above paper. The resulting code is:

-1 constant EOF

: get-char ( ca u -- ca' u' [ch | EOF] )
?dup 0= if drop EOF exit then
over c@ >r 1 /string r>
;

: is-alpha ( ch -- f ) 'a' 'z' 1+ within ; \ adequate for testing

create token 32 chars allot
2variable tok

: init-token ( ca u ) token 0 tok 2! ;

: add-to-token ( ch -- ) tok 2@ + c! 1 tok +! ;

: got-token ( type -- )
cr if ." Word: " else ." Punct: " then
tok 2@ type
init-token
;

: ?got-token ( ca u ) \ To handle tokens left in the buffer e.g. on EOF
tok @ if 1 got-token then \ Only needed for WORD tokens
;

\ The consumer
: parser ( ch -- )
dup is-alpha
if
begin
add-to-token exit
[:] parser.alpha ( ch2 ) \ Re-enter here
dup is-alpha 0=
until
then
?got-token
add-to-token
0 got-token ( Punctuation token )
exit
[:] parser.end
?got-token
;

\ The producer
: decompressor ( ca u -- )
init-token
begin
get-char ( -- ca'u' ch ) \ or ( -- EOF )
dup EOF =
if drop parser.end cr ." End of file" cr exit then
dup
while
dup $FF =
if drop get-char >r get-char ( -- ca' u' ch ) ( R: -- len )
dup parser r> 1
?do dup parser.alpha loop
drop
else
parser
then
repeat
;

init-token
s\" \xFF\x03abc%\xFF\x02-&xyz@qwerty" decompressor .s
\ Displays
Word: aaabc
Punct: %
Punct: -
Punct: -
Punct: &
Word: xyz
Punct: @
Word: qwerty
End of file

Switching between the routines is achieved by calls to different entry
points in the Parser, and by EXIT or ; back to the decompressor. This is
not Standard Forth and uses an extension that I implemented over 10
years ago, tested but never used. I cannot remember my motivation for
doing so perhaps somebody mentioned it as an idea. I'd be pleased if
somebody could point to any previous use of this technique.

This extension is a word called [:] that behaves like : and can only be
used in the middle of a standard colon definition. Usage e.g.
: foo ... [:] bar ... [:] baz ... ;
to create named entry points into colon definition FOO.
Such an entry definition compiles no executable code of its own and
execution of the enclosing definition simply executes the body of the definition as if the alternative entry points weren't there e.g.
: foo 1 . [:] bar 2 . [:] baz 3 . ;
foo 1 2 3
executing the alternative entry points executes the code following
definition of the entry point e.g.
bar 2 3
baz 3
Using BAR etc in another colon definition calls that entry point just
like any standard colon definition to run the code following that entry
point.
An entry point does not use the control stack in any way, therefore it
can be positioned inside any control structure.
An entry point becomes visible immediately its definition is complete,
so it can be called from anywhere in the rest of the enclosing definition.
As a pseudo colon definition an entry point has an execution token that
can be obtained or used by the usual set of words such as ' POSTPONE etc. Execution of code following an entry point can be terminated at any time
using EXIT

In the example above in addition to PARSER there are two other entry
points PARSER.ALPHA (in the middle of a loop) and PARSER.END

There are other uses for [:] entry points:
1. Coroutines (see example above)

2. Recursion by name e.g.
: foo ... [:] bar ... bar ...; \ recurses to BAR or
: foo [foo] ... foo ... ;
The second example can be achieved by using SYNONYM
e.g. SYNONYM FOO RECURSE but the first can include initialisation

3. Obtain the xt of the current definition, which has been requested a
few times on c.l.f e.g.
: x [:] my-xt ['] my-xt ... ; \ Removes the need for LATEST

4. Generators akin to those of Python with next e.g.
variable n : foo n ! exit [:] foo.next n @ 1 n +! ;
1 foo
foo.next ( -- 1 )
foo.next ( -- 2 )

5. Debugging by inserting entry points at which a definition can be run
with known test data on the stack

6. Nested colon definitions e.g. a possible use - unsure of its utility.
: a 1 . [: [:] b 2 . 3 . ;] drop 4 . ;
b 2 3
b is effectively a nested colon definition - forbidden by the standard
--
Gerry

--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.lang.forth

Gerry Jackson <do-not-use@swldwa.uk> writes:

Never having looked at coroutines before I tried implementing the
examples in the above paper. The resulting code is: ...

It would take me a while to understand that, but [:] is cool (I haven't
seen it before), and it lets you do something similar to protothreads.

For coroutines in general you should also read this:

https://doi.org/10.1145/1462166.1462167

It discusses "stackful" coroutines where each coroutine has a separate
call stack that is preserved across coroutine jumps. It's similar to
Forth's cooperative multitasking.
--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.lang.forth

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

https://doi.org/10.1145/1462166.1462167

Ehh, that article is very theoretical. I had forgotten what it was
like, or maybe confused it with a different article. The below is
probably more readable:

https://www.lua.org/doc/jucs04.pdf
--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.lang.forth

Reposted from the discussion "Euroforth 2025 preliminary proceedings"
where it had been misposted.

On 20/01/2026 08:35, Paul Rubin wrote:

albert@spenarnc.xs4all.nl writes:

If you pass an address a as a tail call is it approximately equal
to coroutines:

No I don't think so. The tail call is just a jump to that address
(changes the program counter). A coroutine jump also has to change the stack pointer. See the section "Knuth's coroutines" here:

https://www.chiark.greenend.org.uk/~sgtatham/coroutines.html

Some Forths have a CO primitive that I think is similar. There is
something like it on the Greenarrays processor.

Never having looked at coroutines before I tried implementing the
examples in the above paper. The resulting code is:

-1 constant EOF

: get-char ( ca u -- ca' u' [ch | EOF] )
?dup 0= if drop EOF exit then
over c@ >r 1 /string r>
;

: is-alpha ( ch -- f ) 'a' 'z' 1+ within ; \ adequate for testing

create token 32 chars allot
2variable tok

: init-token ( ca u ) token 0 tok 2! ;

: add-to-token ( ch -- ) tok 2@ + c! 1 tok +! ;

: got-token ( type -- )
cr if ." Word: " else ." Punct: " then
tok 2@ type
init-token
;

: ?got-token ( ca u ) \ To handle tokens left in the buffer e.g. on EOF
tok @ if 1 got-token then \ Only needed for WORD tokens
;

\ The consumer
: parser ( ch -- )
dup is-alpha
if
begin
add-to-token exit
[:] parser.alpha ( ch2 ) \ Re-enter here
dup is-alpha 0=
until
then
?got-token
add-to-token
0 got-token ( Punctuation token )
exit
[:] parser.end
?got-token
;

\ The producer
: decompressor ( ca u -- )
init-token
begin
get-char ( -- ca'u' ch ) \ or ( -- EOF )
dup EOF =
if drop parser.end cr ." End of file" cr exit then
dup
while
dup $FF =
if drop get-char >r get-char ( -- ca' u' ch ) ( R: -- len )
dup parser r> 1
?do dup parser.alpha loop
drop
else
parser
then
repeat
;

init-token
s\" \xFF\x03abc%\xFF\x02-&xyz@qwerty" decompressor .s
\ Displays
Word: aaabc
Punct: %
Punct: -
Punct: -
Punct: &
Word: xyz
Punct: @
Word: qwerty
End of file

Switching between the routines is achieved by calls to different entry
points in the Parser, and by EXIT or ; back to the decompressor. This is
not Standard Forth and uses an extension that I implemented over 10
years ago, tested but never used. I cannot remember my motivation for
doing so perhaps somebody mentioned it as an idea. I'd be pleased if
somebody could point to any previous use of this technique.

This extension is a word called [:] that behaves like : and can only be
used in the middle of a standard colon definition. Usage e.g.
: foo ... [:] bar ... [:] baz ... ;
to create named entry points into colon definition FOO.
Such an entry definition compiles no executable code of its own and
execution of the enclosing definition simply executes the body of the definition as if the alternative entry points weren't there e.g.
: foo 1 . [:] bar 2 . [:] baz 3 . ;
foo 1 2 3
executing the alternative entry points executes the code following
definition of the entry point e.g.
bar 2 3
baz 3
Using BAR etc in another colon definition calls that entry point just
like any standard colon definition to run the code following that entry
point.
An entry point does not use the control stack in any way, therefore it
can be positioned inside any control structure.
An entry point becomes visible immediately its definition is complete,
so it can be called from anywhere in the rest of the enclosing definition.
As a pseudo colon definition an entry point has an execution token that
can be obtained or used by the usual set of words such as ' POSTPONE etc. Execution of code following an entry point can be terminated at any time
using EXIT

In the example above in addition to PARSER there are two other entry
points PARSER.ALPHA (in the middle of a loop) and PARSER.END

There are other uses for [:] entry points:
1. Coroutines (see example above)

2. Recursion by name e.g.
: foo ... [:] bar ... bar ...; \ recurses to BAR, or
: foo [foo] ... foo ... ;
The second example can be achieved by using SYNONYM
e.g. SYNONYM FOO RECURSE but the first can include initialisation

3. Obtain the xt of the current definition, which has been requested a
few times on c.l.f e.g.
: x [:] my-xt ['] my-xt ... ; \ Removes the need for LATEST

4. Generators akin to those of Python with next e.g.
variable n : foo n ! exit [:] foo.next n @ 1 n +! ;
1 foo
foo.next ( -- 1 )
foo.next ( -- 2 )

5. Debugging by inserting entry points at which a definition can be run
with known test data on the stack

6. Nested colon definitions e.g. a possible use - unsure of its utility.
: a 1 . [: [:] b 2 . 3 . ;] drop 4 . ;
b 2 3
b is effectively a nested colon definition - forbidden by the standard
--
Gerry

--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.lang.forth

On 05/04/2026 23:25, Gerry Jackson wrote:
On 05/04/2026 02:02, Paul Rubin wrote:

Gerry Jackson <do-not-use@swldwa.uk> writes:

Never having looked at coroutines before I tried implementing the
examples in the above paper. The resulting code is: ...

It would take me a while to understand that, but [:] is cool (haven't
seen it before),

That's not surprising as I've never posted anything about [:] before.
That's not to say that it's a new concept it's just that I'm unaware of
any previous work that is similar.

and it lets you do something similar to protothreads.

I've never heard of protothreads let alone used them. Apparently they
are used extremely lightweight, stackless threads designed for memory-constrained embedded systems. Th+is sounds like they are
applicable to Forth systems. Do you have any examples of use of
protothreads.

For coroutines in general you should also read this:

https://doi.org/10.1145/1462166.1462167

It discusses "stackful" coroutines where each coroutine has a separate
call stack that is preserved across coroutine jumps. It's similar to
Forth's cooperative multitasking.

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

https://doi.org/10.1145/1462166.1462167

Ehh, that article is very theoretical. I had forgotten what it was
like, or maybe confused it with a different article. The below is
probably more readable:

https://www.lua.org/doc/jucs04.pdf

Thanks for the link, very interesting. According to that paper the Forth implementation in my first post is an asymmetric coroutine as are Lua coroutines which they justify in an appendix, stating "it is easy to demonstrate that symmetric coroutines can be expressed by asymmetric facilities"

According to the paper two fundamental characteristics of a coroutine as follows:
– “the values of data local to a coroutine persist between successive calls”;
– “the execution of a coroutine is suspended as control leaves it, only
to carry on where it left off when control re-enters the coroutine at
some later stage”

For the first point, in my example data local to the parser is retained
but in global variables. That can be made local by putting them in a
separate wordlist. Using Forth local variables doesn't make sense when
[:] is used. If it did make sense then local variable values wouldn't be retained.

For the second point, execution of the parser is certainly suspended but
it doesn't automatically carry on where it left off when control
re-enters. The re-entry point has to be called by name. I would think
that makes it more readable.
--
Gerry

--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.lang.forth

Gerry Jackson <do-not-use@swldwa.uk> writes:

I've never heard of protothreads let alone used them. Apparently they

They are basically a fancier version of Simon Tatham's preprocessor
scheme. In fact I confused the two. See:

https://dunkels.com/adam/pt/index.html

Thanks for the link, very interesting. According to that paper the
Forth implementation in my first post is an asymmetric coroutine as
are Lua coroutines which they justify in an appendix,

I think there's a big difference, which is that in Lua, you can call
something as a coroutine, and it can yield from several levels deep in
function calls and later resume where it left off. Python originally
couldn't do that, but it gained the ability later. It's how
asynchronous i/o works in Python. It also lets you implement
multitasking, by having the tasks avoid any blocking operations and
yield frequently to not hog the cpu.

Forth also often implements something like that, with a cooperative
multitasker API where you PAUSE every so often, and communicate through mailboxes rather than with return values. It's equivalent though.

For the first point, in my example data local to the parser is
retained but in global variables. That can be made local by putting
them in a separate wordlist. Using Forth local variables doesn't make
sense when [:] is used. If it did make sense then local variable
values wouldn't be retained.

Yes, in the C macro system you use static local variables, somewhatlike
Forth globals.

The re-entry point has to be called by name. I would think that makes
it more readable.

Does that mean the caller has to know where the coroutine returns from?
That's more bookkeeping.
--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.lang.forth

In article <10qunhm$1nnbt$1@dont-email.me>,
Gerry Jackson <do-not-use@swldwa.uk> wrote:
<SNIP>

6. Nested colon definitions e.g. a possible use - unsure of its utility.
: a 1 . [: [:] b 2 . 3 . ;] drop 4 . ;
b 2 3
b is effectively a nested colon definition - forbidden by the standard

The term forbidden sneaks in probably by implementors that have
absolutely no intention to implement this.
Normal it would be phrased as,
"A standard Forth is not required to accommodate nested definitions.
A program relying on such has an environmental dependancy"
Note that [: .. ;] is in fact nesting definitions. 1]



In ciforth you can load an extension { } [ ]
Your example
: a 1 . [: [:] b 2 . 3 . ;] drop 4 . ;
then becomes
: a 1 . [ : b 2 . 3 . ; ] b drop 4 . ;
(Maybe with :: ;; that unlinks `b from the dictionary
to make `b private.}

Gerry

1]
Definition or word, or dictionary entry.
Definition: a dictionary entry is a logical part of the dictionary that
bundles the properties of a word/definition.
Definition: It is identified by a handle, the dea (dictionary entry address) CDFLN SX
It has a code address: for executing the word, native code.
It has a data address: contains a pointer to data (buffer, ITC, DTC,)
It has a flag address: individual bits identify immediate smudged etc.
It has a link address: that defines a relation its wordlist
It has a name address: contains a (pointer to) the name
Extra fields can be added by an implementation.
Example a source address: points to the source of a word^H^H^H^H d.e..
Each and all of this fields can be modified without disturbing
the identity of a dea, e.g.
"drop" ALLOCATE$ ' DROP >NFA !

It makes no sense to have a word without a name, old view.
OTOH a d.e. where the name address contains a null pointer
makes perfect sense, new view.
Using dea as an xt :
EXECUTE ( dea -- ?? ) jump to the address found via the cfa.
This can be accomplished while the d.e. is not (yet) linked
into a wordlist, or floating in ALLOCATEd space, or temporary
in a spare dictionary area that is about to be destroyed,
or even if the "word" has no name.

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.21f-Linux NewsLink 1.2

From Newsgroup: comp.lang.forth

On 06/04/2026 01:16, Paul Rubin wrote:

Gerry Jackson <do-not-use@swldwa.uk> writes:

I've never heard of protothreads let alone used them. Apparently they

They are basically a fancier version of Simon Tatham's preprocessor
scheme. In fact I confused the two. See:

https://dunkels.com/adam/pt/index.html

Thanks for the link, very interesting. According to that paper the
Forth implementation in my first post is an asymmetric coroutine as
are Lua coroutines which they justify in an appendix,

I think there's a big difference, which is that in Lua, you can call something as a coroutine, and it can yield from several levels deep in function calls and later resume where it left off.

I presume that means that the coroutine yielding has to have its own
return and data stacks which I've not considered. If that's the case
then an alternative to call by name suggested below should be able to
handle that case.

Python originally

couldn't do that, but it gained the ability later. It's how
asynchronous i/o works in Python. It also lets you implement
multitasking, by having the tasks avoid any blocking operations and
yield frequently to not hog the cpu.

Forth also often implements something like that, with a cooperative multitasker API where you PAUSE every so often, and communicate through mailboxes rather than with return values. It's equivalent though.

...

The re-entry point has to be called by name. I would think that makes
it more readable.

Does that mean the caller has to know where the coroutine returns from? That's more bookkeeping.

Yes and that's presumably undesirable for multi-tasking. A solution to
that could use the fact that the [:] entry point has an xt that can be
stored as data prior to returning (yielding). The best way would be to
have a variant of [:] that saved the xt of the re-entry point in a
deferred word. On re-entry the saved xt would be executed to take
control to the correct place. An alternative would be to pass the
re-entry back to the caller so the it could execute the xt. But that has
the disadvantage that the xt has to be remembered by the caller.
--
Gerry
--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.lang.forth

On 06/04/2026 12:51, albert@spenarnc.xs4all.nl wrote:

In article <10qunhm$1nnbt$1@dont-email.me>,
Gerry Jackson <do-not-use@swldwa.uk> wrote:
<SNIP>

6. Nested colon definitions e.g. a possible use - unsure of its utility.
: a 1 . [: [:] b 2 . 3 . ;] drop 4 . ;
b 2 3
b is effectively a nested colon definition - forbidden by the standard

The term forbidden sneaks in probably by implementors that have
absolutely no intention to implement this.

Hmm I just scanned the Forth 2012 document to see if nested definition
were ambiguous or had an environmental dependency and I couldn't find anything. I always assumed it wasn't permited - perhaps it is.

Normal it would be phrased as,
"A standard Forth is not required to accommodate nested definitions.
A program relying on such has an environmental dependancy"
Note that [: .. ;] is in fact nesting definitions. 1]

In ciforth you can load an extension { } [ ]
Your example
: a 1 . [: [:] b 2 . 3 . ;] drop 4 . ;
then becomes
: a 1 . [ : b 2 . 3 . ; ] b drop 4 . ;

That's interesting but I didn't have the call to b and the drop was
simply to drop the xt of the quotation.

My system can handle nested definitions e.g.
: a 1 . [ : b 2 . 3 . ; ] 4 . ;
a 1 4 ok
b 2 3 ok

It aso handles other types of definitions inside a colon definition i.e. variables etc.

1]
Definition or word, or dictionary entry.
Definition: a dictionary entry is a logical part of the dictionary that bundles the properties of a word/definition.
Definition: It is identified by a handle, the dea (dictionary entry address) CDFLN SX
It has a code address: for executing the word, native code.
It has a data address: contains a pointer to data (buffer, ITC, DTC,)
It has a flag address: individual bits identify immediate smudged etc.
It has a link address: that defines a relation its wordlist
It has a name address: contains a (pointer to) the name
Extra fields can be added by an implementation.
Example a source address: points to the source of a word^H^H^H^H d.e..
Each and all of this fields can be modified without disturbing
the identity of a dea, e.g.
"drop" ALLOCATE$ ' DROP >NFA !

It makes no sense to have a word without a name, old view.
OTOH a d.e. where the name address contains a null pointer
makes perfect sense, new view.
Using dea as an xt :
EXECUTE ( dea -- ?? ) jump to the address found via the cfa.
This can be accomplished while the d.e. is not (yet) linked
into a wordlist, or floating in ALLOCATEd space, or temporary
in a spare dictionary area that is about to be destroyed,
or even if the "word" has no name.

Groetjes Albert

--
Gerry
--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.lang.forth

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

I think there's a big difference, which is that in Lua, you can call >something as a coroutine, and it can yield from several levels deep in >function calls and later resume where it left off. Python originally >couldn't do that, but it gained the ability later. It's how
asynchronous i/o works in Python. It also lets you implement
multitasking, by having the tasks avoid any blocking operations and
yield frequently to not hog the cpu.

I have 100+ cores concurrently. I don't want to yield anything.


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.21f-Linux NewsLink 1.2

From Newsgroup: comp.lang.forth

In article <10r1825$2d8j6$1@dont-email.me>,
Gerry Jackson <do-not-use@swldwa.uk> wrote:

On 06/04/2026 12:51, albert@spenarnc.xs4all.nl wrote:

In article <10qunhm$1nnbt$1@dont-email.me>,
Gerry Jackson <do-not-use@swldwa.uk> wrote:
<SNIP>

6. Nested colon definitions e.g. a possible use - unsure of its utility. >>> : a 1 . [: [:] b 2 . 3 . ;] drop 4 . ;
b 2 3
b is effectively a nested colon definition - forbidden by the standard >>

The term forbidden sneaks in probably by implementors that have
absolutely no intention to implement this.

Hmm I just scanned the Forth 2012 document to see if nested definition
were ambiguous or had an environmental dependency and I couldn't find >anything. I always assumed it wasn't permited - perhaps it is.

You have been bamboozled nu the wording.
No one can forbid an implementation to add a facility like this. The
wording is such to scare implementors like me. Note that this doesn't
interfere at all with compliance to the standard. If it is common
place to add nested compilation they have to add this sooner or later.
The prize is a non-standard program. Point me to a program that
does something useful, and doesn't contain implementation dependant
parts.
Now it is a good time to recapitulate my postings
"The four brackets of the apocalypse."

A good test of whether an architecture is sound, is whether
fullfilling such request is easy.
I'm proud that in all programs I designed,reasonable extension were
easy.

A similar situation applies to "TO must scan". It turns out there
is no standard program that can detect this. It steers implementation
towards a scanning TO.

<SNIP>

--
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.21f-Linux NewsLink 1.2

From Newsgroup: comp.lang.forth

On 4/6/26 4:20 PM, Gerry Jackson wrote:

On 06/04/2026 12:51, albert@spenarnc.xs4all.nl wrote:

In article <10qunhm$1nnbt$1@dont-email.me>,
Gerry Jackson  <do-not-use@swldwa.uk> wrote:
<SNIP>

6. Nested colon definitions e.g. a possible use - unsure of its utility. >>>     : a 1 . [: [:] b 2 . 3 . ;] drop 4 . ;
    b 2 3
    b is effectively a nested colon definition - forbidden by the
standard

The term forbidden sneaks in probably by implementors that have
absolutely no intention to implement this.

Hmm I just scanned the Forth 2012 document to see if nested definition
were ambiguous or had an environmental dependency and I couldn't find anything. I always assumed it wasn't permited - perhaps it is.

It is in section 3.4.5, in particular the 2nd paragraph:

3.4.5
Compilation
A program shall not attempt to nest compilation of definitions. During
the compilation of the current definition, a program shall not execute
any defining word, :NONAME, or any definition that allocates dictionary
data space. The compilation of the current definition may be suspended
using [ (left-bracket) and resumed using ] (right-bracket).

While the compilation of the current definition is suspended, a program
shall not execute any defining word, :NONAME, or any definition that
allocates dictionary data space.


It seems entirely frivolous to me, but maybe it is difficult to do for
certain architectures.

--
Krishna

--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.lang.forth

Krishna Myneni <krishna.myneni@ccreweb.org> writes:

It is in section 3.4.5, in particular the 2nd paragraph:

3.4.5
Compilation
A program shall not attempt to nest compilation of definitions. During
the compilation of the current definition, a program shall not execute
any defining word, :NONAME, or any definition that allocates dictionary
data space. The compilation of the current definition may be suspended
using [ (left-bracket) and resumed using ] (right-bracket).

While the compilation of the current definition is suspended, a program >shall not execute any defining word, :NONAME, or any definition that >allocates dictionary data space.

It seems entirely frivolous to me, but maybe it is difficult to do for >certain architectures.

I think it was existing practice: Most systems did not support nested definitions when Forth-94 was standardized, and I guess that most
systems do not support general nesting to this day, and when they do,
the syntax is system-dependent.

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

From Newsgroup: comp.lang.forth

On 07/04/2026 12:35, albert@spenarnc.xs4all.nl wrote:

A similar situation applies to "TO must scan". It turns out there
is no standard program that can detect this. It steers implementation
towards a scanning TO.

On the contrary, Ruvim posted some code that is a standard program and
which distinguises between a parsing TO and one that sets a flag for a following VALUE to act on.

I can't find the post but the gist of it was (I think):

1 value v1
2 value v2 immediate
: test to v2 v1 ;
Running test with
3 test
A parsing TO will set v2 to 3
A flagging TO will execute v2 during compilation of test because it is immediate. So test will set v1 to 3 leaving v2 unchanged.
--
Gerry
--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.lang.forth

On 4/7/26 11:12 AM, Anton Ertl wrote:

Krishna Myneni <krishna.myneni@ccreweb.org> writes:

It is in section 3.4.5, in particular the 2nd paragraph:

3.4.5
Compilation

...

While the compilation of the current definition is suspended, a program
shall not execute any defining word, :NONAME, or any definition that
allocates dictionary data space.


It seems entirely frivolous to me, but maybe it is difficult to do for
certain architectures.

I think it was existing practice: Most systems did not support nested definitions when Forth-94 was standardized, and I guess that most
systems do not support general nesting to this day, and when they do,
the syntax is system-dependent.

kForth supports :NONAME definitions when the current definition is
suspended. It is the means by which quotations are defined.

: [: postpone [ :noname ; immediate

: ;] postpone ; ] postpone literal ; immediate

It does not support named definitions (definitions which allocate
dictionary space) during suspended compilation of a definition.

--
Krishna

--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.lang.forth

On 07/04/2026 15:28, Krishna Myneni wrote:

On 4/6/26 4:20 PM, Gerry Jackson wrote:

On 06/04/2026 12:51, albert@spenarnc.xs4all.nl wrote:

In article <10qunhm$1nnbt$1@dont-email.me>,
Gerry Jackson  <do-not-use@swldwa.uk> wrote:
<SNIP>

6. Nested colon definitions e.g. a possible use - unsure of its
utility.
    : a 1 . [: [:] b 2 . 3 . ;] drop 4 . ;
    b 2 3
    b is effectively a nested colon definition - forbidden by the
standard

The term forbidden sneaks in probably by implementors that have
absolutely no intention to implement this.

Hmm I just scanned the Forth 2012 document to see if nested definition
were ambiguous or had an environmental dependency and I couldn't find
anything. I always assumed it wasn't permited - perhaps it is.

It is in section 3.4.5, in particular the 2nd paragraph:

3.4.5
Compilation
A program shall not attempt to nest compilation of definitions. During
the compilation of the current definition, a program shall not execute
any defining word, :NONAME, or any definition that allocates dictionary
data space. The compilation of the current definition may be suspended
using [ (left-bracket) and resumed using ] (right-bracket).

While the compilation of the current definition is suspended, a program shall not execute any defining word, :NONAME, or any definition that allocates dictionary data space.

Thanks I missed that. Those statements would seem to rule out quotations except that it could be argued that the definition of [: and ;] does not suspend compilation - its part of the enclosing colon definition.
--
Gerry
--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.lang.forth

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

On 07/04/2026 12:35, albert@spenarnc.xs4all.nl wrote:

A similar situation applies to "TO must scan". It turns out there
is no standard program that can detect this. It steers implementation
towards a scanning TO.

On the contrary, Ruvim posted some code that is a standard program and
which distinguises between a parsing TO and one that sets a flag for a >following VALUE to act on.

I can't find the post but the gist of it was (I think):

1 value v1
2 value v2 immediate
: test to v2 v1 ;
Running test with
3 test
A parsing TO will set v2 to 3
A flagging TO will execute v2 during compilation of test because it is >immediate. So test will set v1 to 3 leaving v2 unchanged.

No it doesn't. It leaves garbage on the stack during compilation,
leading to mostly an error.
I leave it up to the reader whether this counts as a standard program.

I overlooked this clever example.
So I guess my VALUE is non compliant, proven by a contrived test.

It still makes no sense to forbid a flagging implementation.
(Also VALUE's don't make sense, anyway.)

--
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.21f-Linux NewsLink 1.2

From Newsgroup: comp.lang.forth

On 07/04/2026 17:12, Anton Ertl wrote:

Krishna Myneni<krishna.myneni@ccreweb.org> writes:

It is in section 3.4.5, in particular the 2nd paragraph:

3.4.5
Compilation
A program shall not attempt to nest compilation of definitions. During
the compilation of the current definition, a program shall not execute
any defining word, :NONAME, or any definition that allocates dictionary
data space. The compilation of the current definition may be suspended
using [ (left-bracket) and resumed using ] (right-bracket).

While the compilation of the current definition is suspended, a program
shall not execute any defining word, :NONAME, or any definition that
allocates dictionary data space.


It seems entirely frivolous to me, but maybe it is difficult to do for
certain architectures.

I think it was existing practice: Most systems did not support nested definitions when Forth-94 was standardized, and I guess that most
systems do not support general nesting to this day, and when they do,
the syntax is system-dependent.

I agree except that a few systems I tried compiled existing syntax
e.g.

: foo ... [ : bar ... ; ] ... ;

but the results didn't work
--
Gerry

--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.lang.forth

In article <10r5atl$3g8d5$1@dont-email.me>,
Gerry Jackson <do-not-use@swldwa.uk> wrote:

On 07/04/2026 15:28, Krishna Myneni wrote:

On 4/6/26 4:20 PM, Gerry Jackson wrote:

On 06/04/2026 12:51, albert@spenarnc.xs4all.nl wrote:

In article <10qunhm$1nnbt$1@dont-email.me>,
Gerry Jackson  <do-not-use@swldwa.uk> wrote:
<SNIP>

6. Nested colon definitions e.g. a possible use - unsure of its
utility.
    : a 1 . [: [:] b 2 . 3 . ;] drop 4 . ;
    b 2 3
    b is effectively a nested colon definition - forbidden by the >>>>> standard

The term forbidden sneaks in probably by implementors that have
absolutely no intention to implement this.

Hmm I just scanned the Forth 2012 document to see if nested definition
were ambiguous or had an environmental dependency and I couldn't find
anything. I always assumed it wasn't permited - perhaps it is.

It is in section 3.4.5, in particular the 2nd paragraph:

3.4.5
Compilation
A program shall not attempt to nest compilation of definitions. During
the compilation of the current definition, a program shall not execute
any defining word, :NONAME, or any definition that allocates dictionary
data space. The compilation of the current definition may be suspended
using [ (left-bracket) and resumed using ] (right-bracket).

While the compilation of the current definition is suspended, a program
shall not execute any defining word, :NONAME, or any definition that
allocates dictionary data space.

Thanks I missed that. Those statements would seem to rule out quotations >except that it could be argued that the definition of [: and ;] does not >suspend compilation - its part of the enclosing colon definition.

"part of the" a really Jezuitic argument.

It also forbids
: there 3 ;
: test .. [ ' three COMPILE, ] ... ;
a technique that should be kosher.

It is more proof that the term "forbid" has no place in the wording of the restriction. An implementor of [: has options he sees fit, including
- skipping over an area, that is unused by the current definition,
- temperarily compiling to an alternative HERE, transporting back later
to the regular HERE. ( FAR-DP SWAP-DP TRIM approach use for my OO).
After the current definition finishes copy bake to a new HERE.
- using ALLOCATEd space, or
- invoking a c-compiler.

[: ;] renamed { } to ( include :NONAME ) is readily implemented
by the four nestings of the apocalypse:

: { (( (s ({) ; IMMEDIATE
: } >R (}) s) )) R> 'LITERAL EXECUTE ; IMMEDIATE

With a refurbished [ ] it implements unconstrained nesting :

: doit .. [ .. { ..} .. { .. [ .. ] .. } .. ] .. ;

(The four brackets comprise one screen. Only words
from the ciforth kernel needed. So in a proper architecture
it is straightforward. )

--
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.21f-Linux NewsLink 1.2

From Newsgroup: comp.lang.forth

In article <10r5bgp$3gdvd$1@dont-email.me>,
Gerry Jackson <do-not-use@swldwa.uk> wrote:

On 07/04/2026 17:12, Anton Ertl wrote:

Krishna Myneni<krishna.myneni@ccreweb.org> writes:

It is in section 3.4.5, in particular the 2nd paragraph:

3.4.5
Compilation
A program shall not attempt to nest compilation of definitions. During
the compilation of the current definition, a program shall not execute
any defining word, :NONAME, or any definition that allocates dictionary
data space. The compilation of the current definition may be suspended
using [ (left-bracket) and resumed using ] (right-bracket).

While the compilation of the current definition is suspended, a program
shall not execute any defining word, :NONAME, or any definition that
allocates dictionary data space.


It seems entirely frivolous to me, but maybe it is difficult to do for
certain architectures.

I think it was existing practice: Most systems did not support nested
definitions when Forth-94 was standardized, and I guess that most
systems do not support general nesting to this day, and when they do,
the syntax is system-dependent.

I agree except that a few systems I tried compiled existing syntax
e.g.

: foo ... [ : bar ... ; ] ... ;

but the results didn't work

You didn't try ciforth.

~/PROJECT/ciforths/ciforth: lina -a
WANT -nesting-
[ : ISN'T UNIQUE
] : ISN'T UNIQUE
-nesting- : (WARNING) NOT PRESENT, THOUGH WANTED
OK
: hyp*2 [ : SQ DUP * ; ] SQ SWAP SQ + ;
OK
3 4 hyp*2 .
25 OK

( This is the infamous Pythogarean triangle. )

--
Gerry

--
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.21f-Linux NewsLink 1.2

From Newsgroup: comp.lang.forth

On 08/04/2026 11:34, albert@spenarnc.xs4all.nl wrote:

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

On 07/04/2026 12:35, albert@spenarnc.xs4all.nl wrote:

A similar situation applies to "TO must scan". It turns out there
is no standard program that can detect this. It steers implementation
towards a scanning TO.

On the contrary, Ruvim posted some code that is a standard program and
which distinguises between a parsing TO and one that sets a flag for a
following VALUE to act on.

I can't find the post but the gist of it was (I think):

1 value v1
2 value v2 immediate
: test to v2 v1 ;
Running test with
3 test
A parsing TO will set v2 to 3
A flagging TO will execute v2 during compilation of test because it is
immediate. So test will set v1 to 3 leaving v2 unchanged.

No it doesn't. It leaves garbage on the stack during compilation,
leading to mostly an error.

Do you mean your system does that?

My mistake, I should have written:
A flagging TO should ...

I leave it up to the reader whether this counts as a standard program.

Contrived test or not it is standard.

I overlooked this clever example.

As did everybody else until Ruvim devised it.

So I guess my VALUE is non compliant, proven by a contrived test.

Yes

It still makes no sense to forbid a flagging implementation.

I have some sympathy with that but it does ensure that TO has to be on
the same line as the value name and that the value name does occur
immediately after the TO as there can be multiple TOs in succession or
other intervening code (provided TO doesn't leave garbage on the stack).
Anyway surely a flagging TO is slower as it has to test the flag?

(Also VALUE's don't make sense, anyway.)

VALUEs make more sense than some other things in the standard!
--
Gerry
--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.lang.forth

On 07-04-2026 18:12, Anton Ertl wrote:

Krishna Myneni <krishna.myneni@ccreweb.org> writes:

It is in section 3.4.5, in particular the 2nd paragraph:

3.4.5
Compilation
A program shall not attempt to nest compilation of definitions. During
the compilation of the current definition, a program shall not execute
any defining word, :NONAME, or any definition that allocates dictionary
data space. The compilation of the current definition may be suspended
using [ (left-bracket) and resumed using ] (right-bracket).

While the compilation of the current definition is suspended, a program
shall not execute any defining word, :NONAME, or any definition that
allocates dictionary data space.


It seems entirely frivolous to me, but maybe it is difficult to do for
certain architectures.

I think it was existing practice: Most systems did not support nested definitions when Forth-94 was standardized, and I guess that most
systems do not support general nesting to this day, and when they do,
the syntax is system-dependent.

- anton

In 4tH, these are completely equivalent:

: Hello [: ." Hello world" cr ;] execute ;
: Hello :NONAME ." Hello world" cr ; execute ;

Yes, Forth has "references" in order to match IF..THEN thingies. It
works as well for : and ;.

You can even define:

: Hello : World ." Hello world" cr ; ;

.. for that reason, but since it doesn't leave an address, it only works
if you do "world".

In short, this program:

: Hello1 [: ." Hello world" cr ;] execute ;
: Hello2 :NONAME ." Hello world" cr ; execute ;
: Hello3 : World ." Hello world" cr ; ;

Hello1 Hello2 Hello3 World

.. renders:

---8<---
Hello world
Hello world
Hello world
---8<---

Hans Bezemer

--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.lang.forth

On 4/8/26 6:16 AM, albert@spenarnc.xs4all.nl wrote:

In article <10r5bgp$3gdvd$1@dont-email.me>,
Gerry Jackson <do-not-use@swldwa.uk> wrote:

On 07/04/2026 17:12, Anton Ertl wrote:

Krishna Myneni<krishna.myneni@ccreweb.org> writes:

It is in section 3.4.5, in particular the 2nd paragraph:

3.4.5
Compilation
A program shall not attempt to nest compilation of definitions. During >>>> the compilation of the current definition, a program shall not execute >>>> any defining word, :NONAME, or any definition that allocates dictionary >>>> data space. The compilation of the current definition may be suspended >>>> using [ (left-bracket) and resumed using ] (right-bracket).

While the compilation of the current definition is suspended, a program >>>> shall not execute any defining word, :NONAME, or any definition that
allocates dictionary data space.


It seems entirely frivolous to me, but maybe it is difficult to do for >>>> certain architectures.

I think it was existing practice: Most systems did not support nested
definitions when Forth-94 was standardized, and I guess that most
systems do not support general nesting to this day, and when they do,
the syntax is system-dependent.

I agree except that a few systems I tried compiled existing syntax
e.g.

: foo ... [ : bar ... ; ] ... ;

but the results didn't work

You didn't try ciforth.

~/PROJECT/ciforths/ciforth: lina -a
WANT -nesting-
[ : ISN'T UNIQUE
] : ISN'T UNIQUE
-nesting- : (WARNING) NOT PRESENT, THOUGH WANTED
OK
: hyp*2 [ : SQ DUP * ; ] SQ SWAP SQ + ;
OK
3 4 hyp*2 .
25 OK
...

I assume you can also compile :NONAME definitions while the current
definition is suspended in ciforth e.g.

: hyp^2 [ :NONAME dup * ; ] literal dup >r execute swap r> execute + ;
ok
3 4 hyp^2 .
25 ok

Incidentally, is the scope of your definition of SQ limited to the
definition of hyp*2 in your example above? Or is SQ added to the
dictionary like a regular definition?

--
Krishna




--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.lang.forth

On 08/04/2026 12:16, albert@spenarnc.xs4all.nl wrote:

In article <10r5bgp$3gdvd$1@dont-email.me>,
Gerry Jackson <do-not-use@swldwa.uk> wrote:

On 07/04/2026 17:12, Anton Ertl wrote:

Krishna Myneni<krishna.myneni@ccreweb.org> writes:

It is in section 3.4.5, in particular the 2nd paragraph:

3.4.5
Compilation
A program shall not attempt to nest compilation of definitions. During >>>> the compilation of the current definition, a program shall not execute >>>> any defining word, :NONAME, or any definition that allocates dictionary >>>> data space. The compilation of the current definition may be suspended >>>> using [ (left-bracket) and resumed using ] (right-bracket).

While the compilation of the current definition is suspended, a program >>>> shall not execute any defining word, :NONAME, or any definition that
allocates dictionary data space.


It seems entirely frivolous to me, but maybe it is difficult to do for >>>> certain architectures.

I think it was existing practice: Most systems did not support nested
definitions when Forth-94 was standardized, and I guess that most
systems do not support general nesting to this day, and when they do,
the syntax is system-dependent.

I agree except that a few systems I tried compiled existing syntax
e.g.

: foo ... [ : bar ... ; ] ... ;

but the results didn't work

You didn't try ciforth.

Guilty.

~/PROJECT/ciforths/ciforth: lina -a
WANT -nesting-
[ : ISN'T UNIQUE
] : ISN'T UNIQUE
-nesting- : (WARNING) NOT PRESENT, THOUGH WANTED
OK
: hyp*2 [ : SQ DUP * ; ] SQ SWAP SQ + ;

That's the natural syntax to use, why invent another?

OK
3 4 hyp*2 .
25 OK

That also worked on my system

( This is the infamous Pythogarean triangle. )

--
Gerry
--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.lang.forth

On 08/04/2026 17:47, Krishna Myneni wrote:

On 4/8/26 6:16 AM, albert@spenarnc.xs4all.nl wrote:

In article <10r5bgp$3gdvd$1@dont-email.me>,
Gerry Jackson  <do-not-use@swldwa.uk> wrote:

On 07/04/2026 17:12, Anton Ertl wrote:

Krishna Myneni<krishna.myneni@ccreweb.org> writes:

It is in section 3.4.5, in particular the 2nd paragraph:

3.4.5
Compilation
A program shall not attempt to nest compilation of definitions. During >>>>> the compilation of the current definition, a program shall not execute >>>>> any defining word, :NONAME, or any definition that allocates
dictionary
data space. The compilation of the current definition may be suspended >>>>> using [ (left-bracket) and resumed using ] (right-bracket).

While the compilation of the current definition is suspended, a
program
shall not execute any defining word, :NONAME, or any definition that >>>>> allocates dictionary data space.


It seems entirely frivolous to me, but maybe it is difficult to do for >>>>> certain architectures.

I think it was existing practice: Most systems did not support nested
definitions when Forth-94 was standardized, and I guess that most
systems do not support general nesting to this day, and when they do,
the syntax is system-dependent.

I agree except that a few systems I tried compiled existing syntax
e.g.

: foo  ... [ : bar ... ; ] ... ;

but the results didn't work

You didn't try ciforth.

~/PROJECT/ciforths/ciforth: lina -a
WANT -nesting-
[ : ISN'T UNIQUE
] : ISN'T UNIQUE
-nesting- : (WARNING) NOT PRESENT, THOUGH WANTED
  OK
   : hyp*2 [ : SQ DUP * ; ]  SQ SWAP SQ + ;
    OK
    3 4 hyp*2 .
    25  OK
...

I assume you can also compile :NONAME definitions while the current definition is suspended in ciforth e.g.

: hyp^2 [ :NONAME dup * ; ] literal dup >r execute swap r> execute + ;
ok
3 4 hyp^2 .
25  ok

Works on my system. Both HYP^2 and SQ are added to the current wordlist.

Incidentally, is the scope of your definition of SQ limited to the definition of hyp*2 in your example above? Or is SQ added to the
dictionary like a regular definition?

I think I implemented nesting ( at the same time as [:] ) to make
definition of modules easy. e.g. a module definition would call : and
set public and private wowrdlists. So all defining words can be nested
inside a colon defintion. But I never got round to using nested definitions.
--
Gerry
--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.lang.forth

On 08/04/2026 12:07, albert@spenarnc.xs4all.nl wrote:

In article <10r5atl$3g8d5$1@dont-email.me>,
Gerry Jackson <do-not-use@swldwa.uk> wrote:

On 07/04/2026 15:28, Krishna Myneni wrote:

On 4/6/26 4:20 PM, Gerry Jackson wrote:

On 06/04/2026 12:51, albert@spenarnc.xs4all.nl wrote:

In article <10qunhm$1nnbt$1@dont-email.me>,
Gerry Jackson  <do-not-use@swldwa.uk> wrote:
<SNIP>

6. Nested colon definitions e.g. a possible use - unsure of its
utility.
    : a 1 . [: [:] b 2 . 3 . ;] drop 4 . ;
    b 2 3
    b is effectively a nested colon definition - forbidden by the >>>>>> standard

The term forbidden sneaks in probably by implementors that have
absolutely no intention to implement this.

Hmm I just scanned the Forth 2012 document to see if nested definition >>>> were ambiguous or had an environmental dependency and I couldn't find
anything. I always assumed it wasn't permited - perhaps it is.

It is in section 3.4.5, in particular the 2nd paragraph:

3.4.5
Compilation
A program shall not attempt to nest compilation of definitions. During
the compilation of the current definition, a program shall not execute
any defining word, :NONAME, or any definition that allocates dictionary
data space. The compilation of the current definition may be suspended
using [ (left-bracket) and resumed using ] (right-bracket).

While the compilation of the current definition is suspended, a program
shall not execute any defining word, :NONAME, or any definition that
allocates dictionary data space.

Thanks I missed that. Those statements would seem to rule out quotations
except that it could be argued that the definition of [: and ;] does not
suspend compilation - its part of the enclosing colon definition.

"part of the" a really Jezuitic argument.

Oh, I had to look up what that meant.

It also forbids
: there 3 ;
: test .. [ ' three COMPILE, ] ... ;

So it would seem.

a technique that should be kosher.

I agree that should be ok (except that COMPILE, has undefined
interpretation semantics).

It is more proof that the term "forbid" has no place in the wording of the restriction. An implementor of [: has options he sees fit, including
- skipping over an area, that is unused by the current definition,
- temperarily compiling to an alternative HERE, transporting back later
to the regular HERE. ( FAR-DP SWAP-DP TRIM approach use for my OO).
After the current definition finishes copy bake to a new HERE.
- using ALLOCATEd space, or
- invoking a c-compiler.

[: ;] renamed { } to ( include :NONAME ) is readily implemented
by the four nestings of the apocalypse:

: { (( (s ({) ; IMMEDIATE
: } >R (}) s) )) R> 'LITERAL EXECUTE ; IMMEDIATE

With a refurbished [ ] it implements unconstrained nesting :

: doit .. [ .. { ..} .. { .. [ .. ] .. } .. ] .. ;

(The four brackets comprise one screen. Only words
from the ciforth kernel needed. So in a proper architecture
it is straightforward. )

My system has unconstrained nesting but it doesn't need any change to [
and ] - I'd be hard pressed to justify nesting more than one level.
--
Gerry
--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.lang.forth

On 7 Apr 2026 at 21:55:37 CEST, "Gerry Jackson" <do-not-use@swldwa.uk> wrote:

On 07/04/2026 12:35, albert@spenarnc.xs4all.nl wrote:

A similar situation applies to "TO must scan". It turns out there
is no standard program that can detect this. It steers implementation
towards a scanning TO.

On the contrary, Ruvim posted some code that is a standard program and
which distinguises between a parsing TO and one that sets a flag for a following VALUE to act on.

VFX sets a flag for TO and friends and has done so for 30+ years. We have no intention of changing despite the cleverness of Ruvim's detection scheme. We take the "as if" position because
a) it simplifies implementation.
b) no user has complained.

Stephen
--
Stephen Pelc, stephen@vfxforth.com
Wodni & Pelc GmbH
Vienna, Austria
Tel: +44 (0)7803 903612, +34 649 662 974 http://www.vfxforth.com/downloads/VfxCommunity/
free VFX Forth downloads
--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.lang.forth

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

On 4/8/26 6:16 AM, albert@spenarnc.xs4all.nl wrote:

In article <10r5bgp$3gdvd$1@dont-email.me>,
Gerry Jackson <do-not-use@swldwa.uk> wrote:

On 07/04/2026 17:12, Anton Ertl wrote:

Krishna Myneni<krishna.myneni@ccreweb.org> writes:

It is in section 3.4.5, in particular the 2nd paragraph:

3.4.5
Compilation
A program shall not attempt to nest compilation of definitions. During >>>>> the compilation of the current definition, a program shall not execute >>>>> any defining word, :NONAME, or any definition that allocates dictionary >>>>> data space. The compilation of the current definition may be suspended >>>>> using [ (left-bracket) and resumed using ] (right-bracket).

While the compilation of the current definition is suspended, a program >>>>> shall not execute any defining word, :NONAME, or any definition that >>>>> allocates dictionary data space.


It seems entirely frivolous to me, but maybe it is difficult to do for >>>>> certain architectures.

I think it was existing practice: Most systems did not support nested
definitions when Forth-94 was standardized, and I guess that most
systems do not support general nesting to this day, and when they do,
the syntax is system-dependent.

I agree except that a few systems I tried compiled existing syntax
e.g.

: foo ... [ : bar ... ; ] ... ;

but the results didn't work

You didn't try ciforth.

~/PROJECT/ciforths/ciforth: lina -a
WANT -nesting-
[ : ISN'T UNIQUE
] : ISN'T UNIQUE
-nesting- : (WARNING) NOT PRESENT, THOUGH WANTED
OK
: hyp*2 [ : SQ DUP * ; ] SQ SWAP SQ + ;
OK
3 4 hyp*2 .
25 OK
...

I assume you can also compile :NONAME definitions while the current >definition is suspended in ciforth e.g.

: hyp^2 [ :NONAME dup * ; ] literal dup >r execute swap r> execute + ;
ok
3 4 hyp^2 .
25 ok

Actually you can't. After -nesting- the brackets use the data stack extensively.
You enter an isolated world between [ and ] .
Your example could become
"
WANT -nesting- CASE-INSENSITIVE :NONAME

: hyp^2 [ :NONAME dup * ; CONSTANT NONAME ] NONAME dup >r execute swap r> execute + ;
"
Normally you would do

: hyp^2 { dup * } dup >r execute swap r> execute + ;

Incidentally, is the scope of your definition of SQ limited to the
definition of hyp*2 in your example above? Or is SQ added to the
dictionary like a regular definition?

It is added like a regular definition, however.
I have experimented with :: ;; in place of : and ;
The ;; removes inside definitions.
I am not in the habit of proposing

This is all well and cute, but in actual use is only
{ and } as a simple a replacement for both
:NONAME and [: ;] .

What this does for simplification can be seen by the
following altenatives for adding an xt to a set of
real time task:

===========================
\ Regular Forth code:
100 1 EVENT-BUFFER SILVER-QUEUE

\ Activate or deactivate the hammer of EVENT.
: TOGGLE-NOTE-SILVER SILVER-DATA SILVER-INTERFACE ADVANCE-NOTE ;

\ The real time action of the silver tingle.
: RT-SILVER SILVER-QUEUE ['] TOGGLE-NOTE-SILVER TRY ;

' RT-SILVER REALTIME-TASKS SET+

=========================================
\ First step.

100 1 EVENT-BUFFER SILVER-QUEUE

\ The quotation is activate or deactivate the hammer of EVENT.

\ The real time action of the silver tingle.
: RT-SILVER SILVER-QUEUE { SILVER-DATA SILVER-INTERFACE ADVANCE-NOTE } TRY ;

' RT-SILVER REALTIME-TASKS SET+

====================================
\ Final

100 1 EVENT-BUFFER SILVER-QUEUE

\ The quotation is activate or deactivate the hammer of EVENT.

\ The real time action of the silver tingle. Now use { } as :NONAME .
{ SILVER-QUEUE { SILVER-DATA SILVER-INTERFACE ADVANCE-NOTE } TRY } REALTIME-TASKS SET+

========================
\ Using ISO anonymous behaviour.:
100 1 EVENT-BUFFER SILVER-QUEUE

\ The real time action of the silver tingle.
:NONAME SILVER-QUEUE [: SILVER-DATA SILVER-INTERFACE ADVANCE-NOTE ;] TRY ;
REALTIME-TASKS SET+
=========================================

The latter example illustrates how adhoc :NONAME and [: actually are.
Note how the ' and ['] are eliminated even in the ISO case.

--
Krishna

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

From Newsgroup: comp.lang.forth

On 4/9/26 6:01 AM, albert@spenarnc.xs4all.nl wrote:

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

On 4/8/26 6:16 AM, albert@spenarnc.xs4all.nl wrote:

In article <10r5bgp$3gdvd$1@dont-email.me>,
Gerry Jackson <do-not-use@swldwa.uk> wrote:

On 07/04/2026 17:12, Anton Ertl wrote:

Krishna Myneni<krishna.myneni@ccreweb.org> writes:

It is in section 3.4.5, in particular the 2nd paragraph:

3.4.5
Compilation
A program shall not attempt to nest compilation of definitions. During >>>>>> the compilation of the current definition, a program shall not execute >>>>>> any defining word, :NONAME, or any definition that allocates dictionary >>>>>> data space. The compilation of the current definition may be suspended >>>>>> using [ (left-bracket) and resumed using ] (right-bracket).

While the compilation of the current definition is suspended, a program >>>>>> shall not execute any defining word, :NONAME, or any definition that >>>>>> allocates dictionary data space.


It seems entirely frivolous to me, but maybe it is difficult to do for >>>>>> certain architectures.

I think it was existing practice: Most systems did not support nested >>>>> definitions when Forth-94 was standardized, and I guess that most
systems do not support general nesting to this day, and when they do, >>>>> the syntax is system-dependent.

I agree except that a few systems I tried compiled existing syntax
e.g.

: foo ... [ : bar ... ; ] ... ;

but the results didn't work

You didn't try ciforth.

~/PROJECT/ciforths/ciforth: lina -a
WANT -nesting-
[ : ISN'T UNIQUE
] : ISN'T UNIQUE
-nesting- : (WARNING) NOT PRESENT, THOUGH WANTED
OK
: hyp*2 [ : SQ DUP * ; ] SQ SWAP SQ + ;
OK
3 4 hyp*2 .
25 OK
...

I assume you can also compile :NONAME definitions while the current
definition is suspended in ciforth e.g.

: hyp^2 [ :NONAME dup * ; ] literal dup >r execute swap r> execute + ;
ok
3 4 hyp^2 .
25 ok

Actually you can't. After -nesting- the brackets use the data stack extensively.
You enter an isolated world between [ and ] .
Your example could become
"
WANT -nesting- CASE-INSENSITIVE :NONAME

: hyp^2 [ :NONAME dup * ; CONSTANT NONAME ] NONAME dup >r execute swap r> execute + ;
"

So you can never use "[ ... ] LITERAL" when nesting is in effect in
ciforth?

--
Krishna


--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.lang.forth

On 4/8/26 3:48 PM, Gerry Jackson wrote:

On 08/04/2026 17:47, Krishna Myneni wrote:

On 4/8/26 6:16 AM, albert@spenarnc.xs4all.nl wrote:

In article <10r5bgp$3gdvd$1@dont-email.me>,
Gerry Jackson  <do-not-use@swldwa.uk> wrote:

On 07/04/2026 17:12, Anton Ertl wrote:

Krishna Myneni<krishna.myneni@ccreweb.org> writes:

It is in section 3.4.5, in particular the 2nd paragraph:

3.4.5
Compilation
A program shall not attempt to nest compilation of definitions.
During
the compilation of the current definition, a program shall not
execute
any defining word, :NONAME, or any definition that allocates
dictionary
data space. The compilation of the current definition may be
suspended
using [ (left-bracket) and resumed using ] (right-bracket).

While the compilation of the current definition is suspended, a
program
shall not execute any defining word, :NONAME, or any definition that >>>>>> allocates dictionary data space.


It seems entirely frivolous to me, but maybe it is difficult to do >>>>>> for
certain architectures.

I think it was existing practice: Most systems did not support nested >>>>> definitions when Forth-94 was standardized, and I guess that most
systems do not support general nesting to this day, and when they do, >>>>> the syntax is system-dependent.

I agree except that a few systems I tried compiled existing syntax
e.g.

: foo  ... [ : bar ... ; ] ... ;

but the results didn't work

You didn't try ciforth.

~/PROJECT/ciforths/ciforth: lina -a
WANT -nesting-
[ : ISN'T UNIQUE
] : ISN'T UNIQUE
-nesting- : (WARNING) NOT PRESENT, THOUGH WANTED
  OK
   : hyp*2 [ : SQ DUP * ; ]  SQ SWAP SQ + ;
    OK
    3 4 hyp*2 .
    25  OK
...

I assume you can also compile :NONAME definitions while the current
definition is suspended in ciforth e.g.

: hyp^2 [ :NONAME dup * ; ] literal dup >r execute swap r> execute + ;
ok
3 4 hyp^2 .
25  ok

Works on my system. Both HYP^2 and SQ are added to the current wordlist.
...

Thanks, Gerry. I was going to suggest that maybe we can propose to get
the reference to :NONAME removed from the Forth 20xx standard statement
in 3.4.5 Compilation,

"While the compilation of the current definition is suspended, a
program shall not execute any defining word, :NONAME, or any definition
that allocates dictionary data space."

There may not be enough common practice, though.

--
Krishna



--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.lang.forth

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

On 4/9/26 6:01 AM, albert@spenarnc.xs4all.nl wrote:

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

On 4/8/26 6:16 AM, albert@spenarnc.xs4all.nl wrote:

In article <10r5bgp$3gdvd$1@dont-email.me>,
Gerry Jackson <do-not-use@swldwa.uk> wrote:

On 07/04/2026 17:12, Anton Ertl wrote:

Krishna Myneni<krishna.myneni@ccreweb.org> writes:

It is in section 3.4.5, in particular the 2nd paragraph:

3.4.5
Compilation
A program shall not attempt to nest compilation of definitions. During >>>>>>> the compilation of the current definition, a program shall not execute >>>>>>> any defining word, :NONAME, or any definition that allocates dictionary >>>>>>> data space. The compilation of the current definition may be suspended >>>>>>> using [ (left-bracket) and resumed using ] (right-bracket).

While the compilation of the current definition is suspended, a program >>>>>>> shall not execute any defining word, :NONAME, or any definition that >>>>>>> allocates dictionary data space.


It seems entirely frivolous to me, but maybe it is difficult to do for >>>>>>> certain architectures.

I think it was existing practice: Most systems did not support nested >>>>>> definitions when Forth-94 was standardized, and I guess that most
systems do not support general nesting to this day, and when they do, >>>>>> the syntax is system-dependent.

I agree except that a few systems I tried compiled existing syntax
e.g.

: foo ... [ : bar ... ; ] ... ;

but the results didn't work

You didn't try ciforth.

~/PROJECT/ciforths/ciforth: lina -a
WANT -nesting-
[ : ISN'T UNIQUE
] : ISN'T UNIQUE
-nesting- : (WARNING) NOT PRESENT, THOUGH WANTED
OK
: hyp*2 [ : SQ DUP * ; ] SQ SWAP SQ + ;
OK
3 4 hyp*2 .
25 OK
...

I assume you can also compile :NONAME definitions while the current
definition is suspended in ciforth e.g.

: hyp^2 [ :NONAME dup * ; ] literal dup >r execute swap r> execute + ;
ok
3 4 hyp^2 .
25 ok

Actually you can't. After -nesting- the brackets use the data stack extensively.
You enter an isolated world between [ and ] .
Your example could become
"
WANT -nesting- CASE-INSENSITIVE :NONAME

: hyp^2 [ :NONAME dup * ; CONSTANT NONAME ] NONAME dup >r execute swap r> execute + ;
"

So you can never use "[ ... ] LITERAL" when nesting is in effect in
ciforth?

No, but you don't use nesting normally.
I use extra facilities parsimonily.
I never do those LITERAL trick anyway.

--
Krishna

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.21f-Linux NewsLink 1.2

From Newsgroup: comp.lang.forth

In article <10r84nr$9tt0$2@dont-email.me>,
Krishna Myneni <krishna.myneni@ccreweb.org> wrote:

On 4/8/26 3:48 PM, Gerry Jackson wrote:

On 08/04/2026 17:47, Krishna Myneni wrote:

On 4/8/26 6:16 AM, albert@spenarnc.xs4all.nl wrote:

In article <10r5bgp$3gdvd$1@dont-email.me>,
Gerry Jackson  <do-not-use@swldwa.uk> wrote:

On 07/04/2026 17:12, Anton Ertl wrote:

Krishna Myneni<krishna.myneni@ccreweb.org> writes:

It is in section 3.4.5, in particular the 2nd paragraph:

3.4.5
Compilation
A program shall not attempt to nest compilation of definitions.
During
the compilation of the current definition, a program shall not
execute
any defining word, :NONAME, or any definition that allocates
dictionary
data space. The compilation of the current definition may be
suspended
using [ (left-bracket) and resumed using ] (right-bracket).

While the compilation of the current definition is suspended, a
program
shall not execute any defining word, :NONAME, or any definition that >>>>>>> allocates dictionary data space.


It seems entirely frivolous to me, but maybe it is difficult to do >>>>>>> for
certain architectures.

I think it was existing practice: Most systems did not support nested >>>>>> definitions when Forth-94 was standardized, and I guess that most
systems do not support general nesting to this day, and when they do, >>>>>> the syntax is system-dependent.

I agree except that a few systems I tried compiled existing syntax
e.g.

: foo  ... [ : bar ... ; ] ... ;

but the results didn't work

You didn't try ciforth.

~/PROJECT/ciforths/ciforth: lina -a
WANT -nesting-
[ : ISN'T UNIQUE
] : ISN'T UNIQUE
-nesting- : (WARNING) NOT PRESENT, THOUGH WANTED
  OK
   : hyp*2 [ : SQ DUP * ; ]  SQ SWAP SQ + ;
    OK
    3 4 hyp*2 .
    25  OK
...

I assume you can also compile :NONAME definitions while the current
definition is suspended in ciforth e.g.

: hyp^2 [ :NONAME dup * ; ] literal dup >r execute swap r> execute + ;
ok
3 4 hyp^2 .
25  ok

Works on my system. Both HYP^2 and SQ are added to the current wordlist.
...

Thanks, Gerry. I was going to suggest that maybe we can propose to get
the reference to :NONAME removed from the Forth 20xx standard statement
in 3.4.5 Compilation,

"While the compilation of the current definition is suspended, a
program shall not execute any defining word, :NONAME, or any definition
that allocates dictionary data space."

There may not be enough common practice, though.

I propose a different view. A denotation can occupy (dictionary) space, e.g.
a string.
"AAPESTRING" reserves space, and leaves a pointer to the data structure.
Like wise
{ DUP * } defines a behaviour and leaves a pointer. There is actually
not much difference.
In a lispy implementation both can be ALLOCATEd instead of ALLOTed, but
that is neither here nor there.
(OTOH 0x89080 leaves only a stack item, needs no allocation).
This encompasses a lot of what recognizers accomplishes at a low
conceptual price.
E.g. to implement strings like "ORANG UTAN" :
: (( 'AHEAD COMPILE, (FORWARD ; : )) FORWARD) ; \ On of the brackets
Now a string prefix " does approximately
(( &" PARSE ROT )) DLITERAL

Also something like this could work:
AHEAD { '"' PARSE ROT ] THEN DLITERAL

Doing { } in interpretation state wastes a couple of bytes. ;-)

UNUSED .
16844131800 OK

--
Krishna

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.21f-Linux NewsLink 1.2

From Newsgroup: comp.lang.forth

On 4/9/26 9:10 AM, albert@spenarnc.xs4all.nl wrote:

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

...

I assume you can also compile :NONAME definitions while the current
definition is suspended in ciforth e.g.

: hyp^2 [ :NONAME dup * ; ] literal dup >r execute swap r> execute + ; >>>> ok
3 4 hyp^2 .
25 ok

Actually you can't. After -nesting- the brackets use the data stack extensively.
You enter an isolated world between [ and ] .
Your example could become
"
WANT -nesting- CASE-INSENSITIVE :NONAME

: hyp^2 [ :NONAME dup * ; CONSTANT NONAME ] NONAME dup >r execute swap r> execute + ;
"

So you can never use "[ ... ] LITERAL" when nesting is in effect in
ciforth?

No, but you don't use nesting normally.
I use extra facilities parsimonily.
I never do those LITERAL trick anyway.

The sequence "[ ... ] LITERAL" is a Forth staple for computing a
quantity during a suspended definition and compiling the result in the
resumed definition. It appears quite a bit in my code.

--
Krishna

--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.lang.forth

On 4/9/26 9:41 AM, albert@spenarnc.xs4all.nl wrote:

In article <10r84nr$9tt0$2@dont-email.me>,
Krishna Myneni <krishna.myneni@ccreweb.org> wrote:

....

"While the compilation of the current definition is suspended, a
program shall not execute any defining word, :NONAME, or any definition
that allocates dictionary data space."

There may not be enough common practice, though.

I propose a different view. A denotation can occupy (dictionary) space, e.g. a string.
"AAPESTRING" reserves space, and leaves a pointer to the data structure.
Like wise
{ DUP * } defines a behaviour and leaves a pointer. There is actually
not much difference.

The notation " ... }" conflicts directly with the Forth Scientific
Library notation for arrays of different types, unless "}" is simply a delimiter for a parsing word. In your usage, I don't think "{" is a
parsing word.

I remember pointing this out when "{ ... }" was proposed for a newer
version of locals and the notation was changed.

--
Krishna

--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.lang.forth

In article <10r8rgf$i0s4$2@dont-email.me>,
Krishna Myneni <krishna.myneni@ccreweb.org> wrote:

On 4/9/26 9:41 AM, albert@spenarnc.xs4all.nl wrote:

In article <10r84nr$9tt0$2@dont-email.me>,
Krishna Myneni <krishna.myneni@ccreweb.org> wrote:

....

"While the compilation of the current definition is suspended, a
program shall not execute any defining word, :NONAME, or any definition
that allocates dictionary data space."

There may not be enough common practice, though.

I propose a different view. A denotation can occupy (dictionary) space, e.g. >> a string.
"AAPESTRING" reserves space, and leaves a pointer to the data structure.
Like wise
{ DUP * } defines a behaviour and leaves a pointer. There is actually
not much difference.

The notation " ... }" conflicts directly with the Forth Scientific
Library notation for arrays of different types, unless "}" is simply a >delimiter for a parsing word. In your usage, I don't think "{" is a
parsing word.

I remember pointing this out when "{ ... }" was proposed for a newer
version of locals and the notation was changed.

We run out of brackets. Maybe abandon ( ) for comments, and use only \ .
Then ( ) is freed for math formulaes.

--
Krishna

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

From Newsgroup: comp.lang.forth

On 4/9/26 6:23 PM, albert@spenarnc.xs4all.nl wrote:

In article <10r8rgf$i0s4$2@dont-email.me>,
Krishna Myneni <krishna.myneni@ccreweb.org> wrote:

On 4/9/26 9:41 AM, albert@spenarnc.xs4all.nl wrote:

In article <10r84nr$9tt0$2@dont-email.me>,
Krishna Myneni <krishna.myneni@ccreweb.org> wrote:

....

"While the compilation of the current definition is suspended, a
program shall not execute any defining word, :NONAME, or any definition >>>> that allocates dictionary data space."

There may not be enough common practice, though.

I propose a different view. A denotation can occupy (dictionary) space, e.g.
a string.
"AAPESTRING" reserves space, and leaves a pointer to the data structure. >>> Like wise
{ DUP * } defines a behaviour and leaves a pointer. There is actually
not much difference.

The notation " ... }" conflicts directly with the Forth Scientific
Library notation for arrays of different types, unless "}" is simply a
delimiter for a parsing word. In your usage, I don't think "{" is a
parsing word.

I remember pointing this out when "{ ... }" was proposed for a newer
version of locals and the notation was changed.

We run out of brackets. Maybe abandon ( ) for comments, and use only \ .
Then ( ) is freed for math formulaes.

Your idea of using "::" and just extending ";" to handle the nested
named definition (in similar fashion as using ";" with :NONAME) is
workable. Having a ":" in the compilation word would retain consistency.

--
KM

--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.lang.forth

On 07-04-2026 13:35, albert@spenarnc.xs4all.nl wrote:

A similar situation applies to "TO must scan". It turns out there
is no standard program that can detect this. It steers implementation
towards a scanning TO.

Frankly, I consider VALUE one of these Forth errors we never got rid of.
Why, you ask? Because every name basically returns a pointer - unless we
DOES> something different.

Sure, you can have different ways to store a value, but a parsing word? Really? And all of a sudden it should do different things depending on
type? Yuk!

Personally, I do VALUE and TO. But only for VALUE. And the compiler
figures out what the most optimal way of handling this retrieval or
assignment is. Is the address known at compile time, we handle it like a VALUE, otherwise like a VARIABLE.

And yeah, we have FTO and 2TO. I don't like it - but I like some
smart@$$ "TO" even less. What a waste of code.. And what a horrible design.

Hans Bezemer

--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.lang.forth

On 11/04/2026 3:01 am, Hans Bezemer wrote:

On 07-04-2026 13:35, albert@spenarnc.xs4all.nl wrote:

A similar situation applies to "TO must scan". It turns out there
is no standard program that can detect this. It steers implementation
towards a scanning TO.

Frankly, I consider VALUE one of these Forth errors we never got rid of. Why, you ask? Because every name basically returns a pointer - unless we DOES> something different.

Sure, you can have different ways to store a value, but a parsing word? Really? And all of a sudden it should do different things depending on type? Yuk!

Personally, I do VALUE and TO. But only for VALUE. And the compiler figures out what the most optimal way of handling this retrieval or assignment is. Is the address known at compile time, we handle it like a VALUE, otherwise like a VARIABLE.

And yeah, we have FTO and 2TO. I don't like it - but I like some smart@$$ "TO" even less. What a waste of code.. And what a horrible design.

It's an old problem - something that ought not be required, yet appears to
fill a need. In addition to VALUE, I have INTEGER (aka 0 VALUE). Thus far I've not tired of it. Sometimes I could use 2VALUE in an app but have
resisted the urge. The occasions are simply too few to warrant. I provide definitions for 2VALUE 2TO FVALUE FTO should a user really, really, want them.

--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.lang.forth

On Fri, 10 Apr 2026 19:01:36 +0200
Hans Bezemer <the.beez.speaks@gmail.com> wrote:

On 07-04-2026 13:35, albert@spenarnc.xs4all.nl wrote:

A similar situation applies to "TO must scan". It turns out there
is no standard program that can detect this. It steers implementation towards a scanning TO.

Frankly, I consider VALUE one of these Forth errors we never got rid of. Why, you ask? Because every name basically returns a pointer - unless we DOES> something different.

Sure, you can have different ways to store a value, but a parsing word? Really? And all of a sudden it should do different things depending on
type? Yuk!

Personally, I do VALUE and TO. But only for VALUE. And the compiler
figures out what the most optimal way of handling this retrieval or assignment is. Is the address known at compile time, we handle it like a VALUE, otherwise like a VARIABLE.

And yeah, we have FTO and 2TO. I don't like it - but I like some
smart@$$ "TO" even less. What a waste of code.. And what a horrible design.

Hans Bezemer

I agree to this! I stopped using VALUES over 10 years ago when
TO got overloaded. I have not missed them.

In my system the code produced is exactly the same anyway!

BR
Peter

--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.lang.forth

In article <nnd$5fbdae9b$6428335d@7ddbf5ece7eb9625>,
Hans Bezemer <the.beez.speaks@gmail.com> wrote:

On 07-04-2026 13:35, albert@spenarnc.xs4all.nl wrote:

A similar situation applies to "TO must scan". It turns out there
is no standard program that can detect this. It steers implementation
towards a scanning TO.

Frankly, I consider VALUE one of these Forth errors we never got rid of.
Why, you ask? Because every name basically returns a pointer - unless we >DOES> something different.

Sure, you can have different ways to store a value, but a parsing word? >Really? And all of a sudden it should do different things depending on
type? Yuk!

Personally, I do VALUE and TO. But only for VALUE. And the compiler
figures out what the most optimal way of handling this retrieval or >assignment is. Is the address known at compile time, we handle it like a >VALUE, otherwise like a VARIABLE.

And yeah, we have FTO and 2TO. I don't like it - but I like some
smart@$$ "TO" even less. What a waste of code.. And what a horrible design.

In ciforth you can do this:
Prefixes ("recognizers") are supposed to be parsing the remainder
lf tne word, like $DEADBEAT

Abuse follows.

\ In the minimal wordlist, not masking regular @ !
'ONLY >WID CURRENT !
: @ NAME EVALUATE @ ; PREFIX IMMEDIATE
: ! NAME EVALUATE ! ; PREFIX IMMEDIATE
DEFINITINS \ Snap back.

VARIABLE AAP
12 !AAP
@AAP .
12 OK
13 !AAP
@AAP .
13 OK

Just saying.

(I don't recommend this, by the way.)

Hans Bezemer

--
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.21f-Linux NewsLink 1.2

From Newsgroup: comp.lang.forth

On 12/04/2026 6:03 am, albert@spenarnc.xs4all.nl wrote:

In article <nnd$5fbdae9b$6428335d@7ddbf5ece7eb9625>,
Hans Bezemer <the.beez.speaks@gmail.com> wrote:

On 07-04-2026 13:35, albert@spenarnc.xs4all.nl wrote:

A similar situation applies to "TO must scan". It turns out there
is no standard program that can detect this. It steers implementation
towards a scanning TO.

Frankly, I consider VALUE one of these Forth errors we never got rid of.
Why, you ask? Because every name basically returns a pointer - unless we
DOES> something different.

Sure, you can have different ways to store a value, but a parsing word?
Really? And all of a sudden it should do different things depending on
type? Yuk!

Personally, I do VALUE and TO. But only for VALUE. And the compiler
figures out what the most optimal way of handling this retrieval or
assignment is. Is the address known at compile time, we handle it like a
VALUE, otherwise like a VARIABLE.

And yeah, we have FTO and 2TO. I don't like it - but I like some
smart@$$ "TO" even less. What a waste of code.. And what a horrible design.

In ciforth you can do this:
Prefixes ("recognizers") are supposed to be parsing the remainder
lf tne word, like $DEADBEAT

Abuse follows.

\ In the minimal wordlist, not masking regular @ !
'ONLY >WID CURRENT !
: @ NAME EVALUATE @ ; PREFIX IMMEDIATE
: ! NAME EVALUATE ! ; PREFIX IMMEDIATE
DEFINITINS \ Snap back.

VARIABLE AAP
12 !AAP
@AAP .
12 OK
13 !AAP
@AAP .
13 OK

Just saying.

(I don't recommend this, by the way.)

AFAICT the majority of HLL's use 'self-fetching' variables. Setting a
variable required something like := which corresponds to forth's TO.
IMO local variables in forth was less about 'stack juggling' than
simulating the 'look and feel' code of other languages. Forth locals
code uses a fair number of TO's. Hugh once suggested locals ought to
have used @ ! . This would have been very forth-like - but completely
misses what locals aficionados were trying to do!

For me at least, VALUEs are an 'almost CONSTANT' in which TO rarely gets
used. Without that distinction I'd find it hard justifying VALUEs - or
indeed know when to use them. By clearly stating their intent and usage,
they provide semantic value to written code and the language in general.
But I'm not sure ANS ever did say - leaving users to muddle it out for themselves. Locals' use of 'values' and TO only muddied the waters.



--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.lang.forth

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

On 12/04/2026 6:03 am, albert@spenarnc.xs4all.nl wrote:

In article <nnd$5fbdae9b$6428335d@7ddbf5ece7eb9625>,
Hans Bezemer <the.beez.speaks@gmail.com> wrote:

On 07-04-2026 13:35, albert@spenarnc.xs4all.nl wrote:

A similar situation applies to "TO must scan". It turns out there
is no standard program that can detect this. It steers implementation
towards a scanning TO.

Frankly, I consider VALUE one of these Forth errors we never got rid of. >>> Why, you ask? Because every name basically returns a pointer - unless we >>> DOES> something different.

Sure, you can have different ways to store a value, but a parsing word?
Really? And all of a sudden it should do different things depending on
type? Yuk!

Personally, I do VALUE and TO. But only for VALUE. And the compiler
figures out what the most optimal way of handling this retrieval or
assignment is. Is the address known at compile time, we handle it like a >>> VALUE, otherwise like a VARIABLE.

And yeah, we have FTO and 2TO. I don't like it - but I like some
smart@$$ "TO" even less. What a waste of code.. And what a horrible design. >>

In ciforth you can do this:
Prefixes ("recognizers") are supposed to be parsing the remainder
lf tne word, like $DEADBEAT

Abuse follows.

\ In the minimal wordlist, not masking regular @ !
'ONLY >WID CURRENT !
: @ NAME EVALUATE @ ; PREFIX IMMEDIATE
: ! NAME EVALUATE ! ; PREFIX IMMEDIATE
DEFINITINS \ Snap back.

VARIABLE AAP
12 !AAP
@AAP .
12 OK
13 !AAP
@AAP .
13 OK

Just saying.

(I don't recommend this, by the way.)

AFAICT the majority of HLL's use 'self-fetching' variables. Setting a >variable required something like := which corresponds to forth's TO.
IMO local variables in forth was less about 'stack juggling' than
simulating the 'look and feel' code of other languages. Forth locals
code uses a fair number of TO's. Hugh once suggested locals ought to
have used @ ! . This would have been very forth-like - but completely
misses what locals aficionados were trying to do!

For me at least, VALUEs are an 'almost CONSTANT' in which TO rarely gets >used. Without that distinction I'd find it hard justifying VALUEs - or >indeed know when to use them. By clearly stating their intent and usage, >they provide semantic value to written code and the language in general.
But I'm not sure ANS ever did say - leaving users to muddle it out for >themselves. Locals' use of 'values' and TO only muddied the waters.

With indirect code you can also do this, revealing that constants can
be patched:

This leads to

Preliminary estamination to run test code.
1000 CONSTANT SIZE
Preliminary allocated buffer to run test code.
CREATE BUFFIE SIZE CELLS ALLOT

\ production code , pass size on the command line.
: doit 1 ARG[] EVALUATE 'SIZE >DFA !
'BUFFIE SIZE CELLS REALLOT ;

The REALLOT serves a real purpose. In projecteuler problems
buffers can be gigabytes. In a turnkey system they would
land in the executable.

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.21f-Linux NewsLink 1.2

From Newsgroup: comp.lang.forth

On 12-04-2026 04:49, dxf wrote:

On 12/04/2026 6:03 am, albert@spenarnc.xs4all.nl wrote:

In article <nnd$5fbdae9b$6428335d@7ddbf5ece7eb9625>,
Hans Bezemer <the.beez.speaks@gmail.com> wrote:

On 07-04-2026 13:35, albert@spenarnc.xs4all.nl wrote:

A similar situation applies to "TO must scan". It turns out there
is no standard program that can detect this. It steers implementation
towards a scanning TO.

Frankly, I consider VALUE one of these Forth errors we never got rid of. >>> Why, you ask? Because every name basically returns a pointer - unless we >>> DOES> something different.

Sure, you can have different ways to store a value, but a parsing word?
Really? And all of a sudden it should do different things depending on
type? Yuk!

Personally, I do VALUE and TO. But only for VALUE. And the compiler
figures out what the most optimal way of handling this retrieval or
assignment is. Is the address known at compile time, we handle it like a >>> VALUE, otherwise like a VARIABLE.

And yeah, we have FTO and 2TO. I don't like it - but I like some
smart@$$ "TO" even less. What a waste of code.. And what a horrible design. >>

In ciforth you can do this:
Prefixes ("recognizers") are supposed to be parsing the remainder
lf tne word, like $DEADBEAT

Abuse follows.

\ In the minimal wordlist, not masking regular @ !
'ONLY >WID CURRENT !
: @ NAME EVALUATE @ ; PREFIX IMMEDIATE
: ! NAME EVALUATE ! ; PREFIX IMMEDIATE
DEFINITINS \ Snap back.

VARIABLE AAP
12 !AAP
@AAP .
12 OK
13 !AAP
@AAP .
13 OK

Just saying.

(I don't recommend this, by the way.)

AFAICT the majority of HLL's use 'self-fetching' variables. Setting a variable required something like := which corresponds to forth's TO.
IMO local variables in forth was less about 'stack juggling' than
simulating the 'look and feel' code of other languages.
Without that distinction I'd find it hard justifying VALUEs - or
indeed know when to use them. By clearly stating their intent and usage, they provide semantic value to written code and the language in general.
But I'm not sure ANS ever did say - leaving users to muddle it out for themselves. Locals' use of 'values' and TO only muddied the waters.

For me at least, VALUEs are an 'almost CONSTANT' in which TO rarely
gets used.

That's fun, you know! That's what I considered them when I created them!
From the 4tH manual:

"A value is a cross-over between a variable and a constant. (..) In many aspects, values behave like variables and can replace variables. The
only thing you cannot do is make arrays of values. A value is not a
literal expression either, so you can't use them to size arrays. In
fact, a value is a variable that behaves in certain aspects like a
constant."

AFAICT the majority of HLL's use 'self-fetching' variables.

Yeah. I know. I've been contemplating that when considering what my
version of C-- would look like. The name from a variable would just
return its pointer, so:

int c;
int b;

c := 9;
b := *c+5;

Note c and b are rendered as pointers, *not* values. Which is equivalent to:

variable c
variable b

9 c !
c @ 5 + b !

Yeah, := also fixes the "=" / "==" issue. Which I still have in
uBasic/4tH. I mean:

c = b = 10

Doesn't assign 10 to b and c; it assigns the result of (b=10) to c
(which if true equals to "1").

Forth locals
code uses a fair number of TO's. Hugh once suggested locals ought to
have used @ ! . This would have been very forth-like - but completely misses what locals aficionados were trying to do!

You can do both in 4tH, although the !/@ is the leanest of all implementations.

Although in 4tH VALUEs and VARIABLEs are basically the same (4tH
converts VARIABLES to VALUES - and vice versa, depending on the
situation), I tend to use variables, unless I want to do initialization.

Variables are much more flexible IMHO, because you can transfer their
address without a hassle. And I don't particularly like parsing words.
Or functional duplicates without any additional advantages. Or wasting
two tokens I could have used for other stuff.

VALUE is a thing I added to avoid the hassle of converting programs I
port. Like ?DO, which I don't particularly like either. Two words in a
loop making largely the same decision. Yeah. Great. Very clever.

I love how bad designs and half assed concepts make their way into Forth
and never get eradicated. Yeah. Love it.

I mean - I've made some stupid design errors in my time. And at one
point or another I always had to pay for that foolishness. Do you think
it's fun adapting tens of programs, testing them before they are
readmitted in the repository? Personally, I don't think so. But leaving
that stuff in is worse IMHO.

Hans Bezemer

--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.lang.forth

On 12-04-2026 12:13, albert@spenarnc.xs4all.nl wrote:

For me at least, VALUEs are an 'almost CONSTANT' in which TO rarely gets
used.

In a sense, CONSTANTs are *almost* VALUEs:

10 constant ten ok
16 ' ten ! ok
ten . 16 ok

It won't work like that in 4tH (because ' ten would return "10"), but it
works fine in most Forths since '78.

Using this definition:

: reconstant state @ if postpone ['] postpone ! else ' ! then ;
immediate

.. you could write:

16 RECONSTANT ten

.. and you'd *almost* have a VALUE. Cool, huh? :-)

Hans Bezemer


--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.lang.forth

On 13/04/2026 1:39 am, Hans Bezemer wrote:

On 12-04-2026 12:13:

For me at least, VALUEs are an 'almost CONSTANT' in which TO rarely gets >>> used. 

In a sense, CONSTANTs are *almost* VALUEs:

10 constant ten  ok
16 ' ten !  ok
ten . 16  ok

It won't work like that in 4tH (because ' ten would return "10"), but it works fine in most Forths since '78.

It probably needs a >BODY . Forth-in-ROM then no cigar. Inlining compilers?

Using this definition:

  : reconstant state @ if postpone ['] postpone ! else ' ! then ; immediate

.. you could write:

  16 RECONSTANT ten

.. and you'd *almost* have a VALUE. Cool, huh?  :-)

Do away with CONSTANTs and keep VALUEs ? :)

--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.lang.forth

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

On 12/04/2026 6:03 am, albert@spenarnc.xs4all.nl wrote:

In article <nnd$5fbdae9b$6428335d@7ddbf5ece7eb9625>,
Hans Bezemer <the.beez.speaks@gmail.com> wrote:

On 07-04-2026 13:35, albert@spenarnc.xs4all.nl wrote:

A similar situation applies to "TO must scan". It turns out there
is no standard program that can detect this. It steers implementation
towards a scanning TO.

Frankly, I consider VALUE one of these Forth errors we never got rid of. >>> Why, you ask? Because every name basically returns a pointer - unless we >>> DOES> something different.

Sure, you can have different ways to store a value, but a parsing word?
Really? And all of a sudden it should do different things depending on
type? Yuk!

Personally, I do VALUE and TO. But only for VALUE. And the compiler
figures out what the most optimal way of handling this retrieval or
assignment is. Is the address known at compile time, we handle it like a >>> VALUE, otherwise like a VARIABLE.

And yeah, we have FTO and 2TO. I don't like it - but I like some
smart@$$ "TO" even less. What a waste of code.. And what a horrible design. >>

In ciforth you can do this:
Prefixes ("recognizers") are supposed to be parsing the remainder
lf tne word, like $DEADBEAT

Abuse follows.

\ In the minimal wordlist, not masking regular @ !
'ONLY >WID CURRENT !
: @ NAME EVALUATE @ ; PREFIX IMMEDIATE
: ! NAME EVALUATE ! ; PREFIX IMMEDIATE
DEFINITINS \ Snap back.

VARIABLE AAP
12 !AAP
@AAP .
12 OK
13 !AAP
@AAP .
13 OK

Just saying.

(I don't recommend this, by the way.)

AFAICT the majority of HLL's use 'self-fetching' variables. Setting a

Not so algol 68. no l-value and r-values.
real r;
means that r is a name to designate a memory location where a real
can be stored. r is of type "ref real" (5.4 is of type real , really).
If a compiler sees
a := b+c;
It says, hmm a is the place where I can store the result of the calculation.
In b+c it concludes that it cannot add references. So this is
a coercion, forcing dereferencing a and b.
This is a simular situation in the expression 5.1 + 17
There is no module to add a fp to an integer. So 17 is widened to a
fp number.

variable required something like := which corresponds to forth's TO.
IMO local variables in forth was less about 'stack juggling' than
simulating the 'look and feel' code of other languages. Forth locals
code uses a fair number of TO's. Hugh once suggested locals ought to
have used @ ! . This would have been very forth-like - but completely
misses what locals aficionados were trying to do!

For me at least, VALUEs are an 'almost CONSTANT' in which TO rarely gets >used. Without that distinction I'd find it hard justifying VALUEs - or >indeed know when to use them. By clearly stating their intent and usage, >they provide semantic value to written code and the language in general.
But I'm not sure ANS ever did say - leaving users to muddle it out for >themselves. Locals' use of 'values' and TO only muddied the waters.

--
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.21f-Linux NewsLink 1.2

From Newsgroup: comp.lang.forth

On 13-04-2026 02:54, dxf wrote:

On 13/04/2026 1:39 am, Hans Bezemer wrote:

On 12-04-2026 12:13:

For me at least, VALUEs are an 'almost CONSTANT' in which TO rarely gets >>>> used.

In a sense, CONSTANTs are *almost* VALUEs:

10 constant ten  ok
16 ' ten !  ok
ten . 16  ok

It won't work like that in 4tH (because ' ten would return "10"), but it works fine in most Forths since '78.

It probably needs a >BODY . Forth-in-ROM then no cigar. Inlining compilers?

This is just plain gForth.. :-) Copied straight from the terminal.

Do away with CONSTANTs and keep VALUEs ? :)

Nah -- 4tH inlines all constants. And all compiled code in 4tH is R/O.
In 4tH, VALUEs are obviously slower than CONSTANTs (see below). Not a
good plan IMHO. ;-)

Giving CONSTANTS an initial value, just like Forth-79 - fine;
Dropping VALUEs (a lot more work after 30 years of doing it this way).
Grrrr - alrighty then;
Do away with CONSTANTs and keep VALUEs - NO!

Hans Bezemer

CODE (VALUE) DFREE (1); a = (cell) Object->Offset + OPERAND;
VAR (a); DPUSH (Vars [(unsigned) a]); NEXT;

CODE (LITERAL) DFREE (1); DPUSH (OPERAND); NEXT;






--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.lang.forth

Gerry Jackson <do-not-use@swldwa.uk> writes:

I presume that means that the coroutine yielding has to have its own
return and data stacks which I've not considered. If that's the case
then an alternative to call by name suggested below should be able to
handle that case.

Yes, that's correct about separate stacks. I'm not sure about the call
by name alternative. I think Forth does ok with multi-tasking (when
supported) instead of stackful coroutines.
--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.lang.forth

dxf <dxforth@gmail.com> writes:

IMO local variables in forth was less about 'stack juggling' than
simulating the 'look and feel' code of other languages. Forth locals
code uses a fair number of TO's. Hugh once suggested locals ought to
have used @ ! . This would have been very forth-like - but completely
misses what locals aficionados were trying to do!

When I've used locals it's been to avoid contortions reaching into the
stack, including the floating point stack, where FPICK is non-standard.
There's also the realization that computer memory except for a few
specialized Forth chips is always made from RAM. So ideological
devotion to a pure stack VM seems to pass up perfectly good hardware capabilities.

Gforth does support address-like locals if you want to use them.
--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.lang.forth

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

Gerry Jackson <do-not-use@swldwa.uk> writes:

I presume that means that the coroutine yielding has to have its own
return and data stacks which I've not considered. If that's the case
then an alternative to call by name suggested below should be able to
handle that case.

Yes, that's correct about separate stacks. I'm not sure about the call
by name alternative. I think Forth does ok with multi-tasking (when >supported) instead of stackful coroutines.

If you swap return stacks, then in my opinion they are no longer
coroutines in Forth. PAUSE doesn't implement coroutines in any
meaningful sense.

"
\ Switch to hex for the duration of the definition.
VARIABLE BASE-SAVE
: HEX: BASE @ BASE-SAVE ! HEX CO BASE-SAVE @ BASE ! ;
: .x HEX: . ;
12 .x
C OK

"

If you swap data stacks, coroutines are much less useful.

"
WANT decorated

: print-stack .S CO .S ;

: add + ;

' print-stack ' add decorated

1 3 add
S[ 1 3 ] OK
S[ 4 ] OK
"
--
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.21f-Linux NewsLink 1.2

From Newsgroup: comp.lang.forth

On 23/04/2026 4:18 am, Paul Rubin wrote:

dxf <dxforth@gmail.com> writes:

IMO local variables in forth was less about 'stack juggling' than
simulating the 'look and feel' code of other languages. Forth locals
code uses a fair number of TO's. Hugh once suggested locals ought to
have used @ ! . This would have been very forth-like - but completely
misses what locals aficionados were trying to do!

When I've used locals it's been to avoid contortions reaching into the
stack, including the floating point stack, where FPICK is non-standard. There's also the realization that computer memory except for a few specialized Forth chips is always made from RAM. So ideological
devotion to a pure stack VM seems to pass up perfectly good hardware capabilities.

Why would you be "reaching into the stack", engaging in "contortions",
when forth advice is the opposite? The level of emotive rhetoric that accompanies locals is such that I conclude it is about the looks.
FPICK would be more common that flocals.

Gforth does support address-like locals if you want to use them.

When I've used FP (not often) FVARIABLE was fine. I believe FSL offers
other options should users consider it inadequate.
--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.lang.forth

On 22-04-2026 20:18, Paul Rubin wrote:

dxf <dxforth@gmail.com> writes:

IMO local variables in forth was less about 'stack juggling' than
simulating the 'look and feel' code of other languages. Forth locals
code uses a fair number of TO's. Hugh once suggested locals ought to
have used @ ! . This would have been very forth-like - but completely
misses what locals aficionados were trying to do!

When I've used locals it's been to avoid contortions reaching into the
stack, including the floating point stack, where FPICK is non-standard. There's also the realization that computer memory except for a few specialized Forth chips is always made from RAM. So ideological
devotion to a pure stack VM seems to pass up perfectly good hardware capabilities.

Gforth does support address-like locals if you want to use them.

If you want to use a language that is "ideologically devoted" to the architecture, maybe you shouldn't use Forth at all - and stick with C. I
mean, it's IMHO a lame excuse to use the long known discrepancy between
common hardware and Forths classic architecture to justify your use of
locals.

I know there are situations when there are six values on the data stack
and four on the return stack which leave you with few other options. But
you can always use vanilla variables or an extra stack (which is trivial
to implement) to remedy that.

Using Forth means being resourceful. Not to choose the most convenient
and lazy solution imaginable.

Hans Bezemer



--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.lang.forth

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

I know there are situations when there are six values on the data
stack and four on the return stack which leave you with few other
options. But you can always use vanilla variables or an extra stack
(which is trivial to implement) to remedy that.

Using Forth means being resourceful. Not to choose the most convenient
and lazy solution imaginable.

Stack allocation is efficient because stack storage is released when the function returns. Global variables instead occupy storage even when the function isn't in use. And, implementing an extra stack under the
interpreter is both extra contortions and extra overhead. "Resourceful"
sounds more like "masochistic" here. I thought the idea was to do the straightforward thing. There is really something that I'm missing.

I do remember writing some words a while ago to implement multiple
stacks, so there are reasons to want those sometimes.
--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.lang.forth

On 25/04/2026 3:36 am, Paul Rubin wrote:

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

I know there are situations when there are six values on the data
stack and four on the return stack which leave you with few other
options. But you can always use vanilla variables or an extra stack
(which is trivial to implement) to remedy that.

Using Forth means being resourceful. Not to choose the most convenient
and lazy solution imaginable.

Stack allocation is efficient because stack storage is released when the function returns. Global variables instead occupy storage even when the function isn't in use. And, implementing an extra stack under the interpreter is both extra contortions and extra overhead. "Resourceful" sounds more like "masochistic" here. I thought the idea was to do the straightforward thing. There is really something that I'm missing.
...

Forth advocates cautious use of globals. If it aids stack flow, efficiency, then use it. It's the *belief* locals are efficient, can replace stack ops, replace thinking, that is mistaken and leads to inefficiency. Even with
the resources, the fancy compilers, forth users still favour stack ops and thinking. So much so locals users have to use 'time saving' and 'ease' as justification.

c.l.f is traditionally political and controversial - and that's fine. But
on reddit forth where it's more laid back, locals don't get anything like
the support or coverage. If anything, there seems to be push-back - old
hands correcting unwarranted notions that beginners may have picked up.

--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.lang.forth

dxf <dxforth@gmail.com> writes:

Forth advocates cautious use of globals. If it aids stack flow, efficiency, then use it. It's the *belief* locals are efficient, can replace stack ops, replace thinking, that is mistaken and leads to inefficiency. Even with
the resources, the fancy compilers, forth users still favour stack ops and thinking. So much so locals users have to use 'time saving' and 'ease' as justification.

In a simple interpreter, can be inefficient, but that doesn't bother me
too much. "Time saving" and "ease" count for a lot. That's why Forth
was developed in the first place if I'm not mistaken. To be quicker and
easier than programming in assembly language, though much slower.

In asm though, one can program in a stack-oriented style while still
accessing the stack interior. So Forth has lost something by
comparison, ISTM.

I once wrote a function that used floating-point locals and was
recursive, so globals wouldn't have worked, and I didn't see a way to use
stack juggling, and implementing an auxiliary stack sounded absurd.
So I saw no way to avoid the locals.

It occurs to me now that I could maybe get the binary float
representations using "F," and juggle them on to the D and R stacks, but
yecch.

c.l.f is traditionally political and controversial - and that's fine. But
on reddit forth where it's more laid back, locals don't get anything like
the support or coverage. If anything, there seems to be push-back - old hands correcting unwarranted notions that beginners may have picked up.

I'm not sure what you mean here. Do you mean CLF is more pro-locals
than Reddit Forth?
--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.lang.forth

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

dxf <dxforth@gmail.com> writes:

<SNIP>

I once wrote a function that used floating-point locals and was
recursive, so globals wouldn't have worked, and I didn't see a way to use >stack juggling, and implementing an auxiliary stack sounded absurd.
So I saw no way to avoid the locals.

Practical recursion that use fp are e.g. recursive integration algorithms.
(Cut the interval in two, investigate if the precision is sufficient.
If not, split.)
Now that is elegant in C, and not portable in Forth, because an 8
level deep stack is woo-fully inadequate.


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.21f-Linux NewsLink 1.2

From Newsgroup: comp.lang.forth

On 25/04/2026 4:31 pm, Paul Rubin wrote:

dxf <dxforth@gmail.com> writes:

Forth advocates cautious use of globals. If it aids stack flow, efficiency, >> then use it. It's the *belief* locals are efficient, can replace stack ops, >> replace thinking, that is mistaken and leads to inefficiency. Even with
the resources, the fancy compilers, forth users still favour stack ops and >> thinking. So much so locals users have to use 'time saving' and 'ease' as >> justification.

In a simple interpreter, can be inefficient, but that doesn't bother me
too much. "Time saving" and "ease" count for a lot. That's why Forth
was developed in the first place if I'm not mistaken. To be quicker and easier than programming in assembly language, though much slower.

I'd rather use a HLL than asm to write an app too. But each HLL has its methods which one violates to the detriment of the language. Moore didn't introduce locals and made it plain what he thinks.

In asm though, one can program in a stack-oriented style while still accessing the stack interior. So Forth has lost something by
comparison, ISTM.

I once wrote a function that used floating-point locals and was
recursive, so globals wouldn't have worked, and I didn't see a way to use stack juggling, and implementing an auxiliary stack sounded absurd.
So I saw no way to avoid the locals.

It occurs to me now that I could maybe get the binary float
representations using "F," and juggle them on to the D and R stacks, but yecch.

Perhaps Wil Baden's locals scheme:

https://www.taygeta.com/fsl/library/fsl-util.fs

c.l.f is traditionally political and controversial - and that's fine. But >> on reddit forth where it's more laid back, locals don't get anything like
the support or coverage. If anything, there seems to be push-back - old
hands correcting unwarranted notions that beginners may have picked up.

I'm not sure what you mean here. Do you mean CLF is more pro-locals
than Reddit Forth?

More Game of Thrones.

--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.lang.forth

On 25-04-2026 08:31, Paul Rubin wrote:

In asm though, one can program in a stack-oriented style while still accessing the stack interior. So Forth has lost something by
comparison, ISTM.

I once wrote a function that used floating-point locals and was
recursive, so globals wouldn't have worked, and I didn't see a way to use stack juggling, and implementing an auxiliary stack sounded absurd.
So I saw no way to avoid the locals.

"It seems to me" is not a valid argument. Your impression may be vastly different from mine. So - since "what can be asserted without evidence
can also be dismissed without evidence", let's assume there is no
tangible loss.

I think you refer to processors like the Z80. Frankly, although I wrote
quite some Z80 programs in my time, I rarely used stack instructions in
great quantity. But I feel what you're saying.

The Z80 has three 16-bit pairs of registers - and a single 8 bit one.
Plus you can use shadow registers. I remember encoding some Marcel
Hendrix string words from "Vijgeblad" in Z80 assembly using that
technique and entering them as code definitions (SMUDGE).

My own Forth preprocessor started with a handful of registers. Later I
added a string stack - but kept the registers intact. Still, I barely
ever use those registers - although the preprocessor lacks words like
*SWAP* or *ROT.*

First of all, because the stack allows recursion. Second, because you
never know what words may have used those registers. And even lacking
*SWAP* and *ROT* I often get away with it.

So - sure: I agree it may be handy to have a few globals at your
convenience, but IMHO, often LD SP, nnnn is all you need. :-)

The rest is just lame excuses and laziness.

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

From Newsgroup: comp.lang.forth

On 25-04-2026 14:06, dxf wrote:

Perhaps Wil Baden's locals scheme:

https://www.taygeta.com/fsl/library/fsl-util.fs

We do have N>R (https://forth-standard.org/standard/tools/NtoR). So if
the whole problem is "there is no more room on the FP stack", there is a
way out.

HB

--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.lang.forth

On 25/04/2026 11:11 pm, Hans Bezemer wrote:

On 25-04-2026 14:06, dxf wrote:

Perhaps Wil Baden's locals scheme:

https://www.taygeta.com/fsl/library/fsl-util.fs

We do have N>R (https://forth-standard.org/standard/tools/NtoR). So if the whole problem is "there is no more room on the FP stack", there is a way out.

Occasionally there's a proposal for F>R FR> but interest has always been lacking - despite it potentially addressing 'stack juggling', recursion etc. How to explain other than 'solution looking for a problem'? ISTM locals
are the same. In the following reply, the underwhelment is palpable.

https://youtu.be/V9ES9UZHaag?t=3065
--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.lang.forth

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

We do have N>R (https://forth-standard.org/standard/tools/NtoR). So if
the whole problem is "there is no more room on the FP stack", there is
a way out.

That must be pretty new (it's not in gforth 0.7.3) so I wonder how
helpful it really is. We've done without it all this time after all.
--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.lang.forth

On 26-04-2026 05:33, dxf wrote:

On 25/04/2026 11:11 pm, Hans Bezemer wrote:

On 25-04-2026 14:06, dxf wrote:

Perhaps Wil Baden's locals scheme:

https://www.taygeta.com/fsl/library/fsl-util.fs

We do have N>R (https://forth-standard.org/standard/tools/NtoR). So if the whole problem is "there is no more room on the FP stack", there is a way out.

Occasionally there's a proposal for F>R FR> but interest has always been lacking - despite it potentially addressing 'stack juggling', recursion etc. How to explain other than 'solution looking for a problem'? ISTM locals
are the same. In the following reply, the underwhelment is palpable.

https://youtu.be/V9ES9UZHaag?t=3065

I've got two FP systems, but even high level it isn't too hard:

DEFINED] ZenFP [IF]
: f>r r> -rot >r >r >r ;
: fr> r> r> r> rot >r ;
[ELSE]
[UNDEFINED] float>exp [IF] [ABORT] [THEN]
: f>r float>exp r> swap >r -rot >r >r >r ;
: fr> r> r> r> rot r> swap >r exp>float ;
[THEN]

Zen float uses the stack - and an FP number takes two cells.

The other uses an FP stack - and an FP number takes three cells. You can
get an FP number on the data stack using FLOAT>EXP, which results in a
signed mantissa and a signed exponent. Of course, EXP>FLOAT does the
reverse.

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

From Newsgroup: comp.lang.forth

On 07-04-2026 18:12, Anton Ertl wrote:

Krishna Myneni <krishna.myneni@ccreweb.org> writes:

It is in section 3.4.5, in particular the 2nd paragraph:

3.4.5
Compilation
A program shall not attempt to nest compilation of definitions. During
the compilation of the current definition, a program shall not execute
any defining word, :NONAME, or any definition that allocates dictionary
data space. The compilation of the current definition may be suspended
using [ (left-bracket) and resumed using ] (right-bracket).

While the compilation of the current definition is suspended, a program
shall not execute any defining word, :NONAME, or any definition that
allocates dictionary data space.


It seems entirely frivolous to me, but maybe it is difficult to do for
certain architectures.

I think it was existing practice: Most systems did not support nested definitions when Forth-94 was standardized, and I guess that most
systems do not support general nesting to this day, and when they do,
the syntax is system-dependent.

- anton

4tH has supported nested definitions since its inception. But - agreed -
it doesn't have a dictionary, which makes the whole thing a lot easier.

You see, the 4tH ":" word dumps a location and a reference on the
control stack - and compiles a BRANCH. Any nested definition does the
same thing. ":NONAME" compiles a location as a literal and then does the
same thing as ":".

That's all.

Hans Bezemer

--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.lang.forth

In article <10sqcrp$35rsn$1@dont-email.me>,
Hans Bezemer <the.beez.speaks@gmail.com> wrote:

On 07-04-2026 18:12, Anton Ertl wrote:

Krishna Myneni <krishna.myneni@ccreweb.org> writes:

It is in section 3.4.5, in particular the 2nd paragraph:

3.4.5
Compilation
A program shall not attempt to nest compilation of definitions. During
the compilation of the current definition, a program shall not execute
any defining word, :NONAME, or any definition that allocates dictionary
data space. The compilation of the current definition may be suspended
using [ (left-bracket) and resumed using ] (right-bracket).

While the compilation of the current definition is suspended, a program
shall not execute any defining word, :NONAME, or any definition that
allocates dictionary data space.


It seems entirely frivolous to me, but maybe it is difficult to do for
certain architectures.

I think it was existing practice: Most systems did not support nested
definitions when Forth-94 was standardized, and I guess that most
systems do not support general nesting to this day, and when they do,
the syntax is system-dependent.

- anton

4tH has supported nested definitions since its inception. But - agreed -
it doesn't have a dictionary, which makes the whole thing a lot easier.

You see, the 4tH ":" word dumps a location and a reference on the
control stack - and compiles a BRANCH. Any nested definition does the
same thing. ":NONAME" compiles a location as a literal and then does the
same thing as ":".

ciforth does approximately the same thing. A dictionary and wordlists
doesnot make this difficult. However an anonymous definition is
bracketed with { } . :NONAME ending with a semi colon is a mistake.

That's all.

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.21f-Linux NewsLink 1.2

From Newsgroup: comp.lang.forth

On 29-04-2026 10:49, albert@spenarnc.xs4all.nl wrote:

In article <10sqcrp$35rsn$1@dont-email.me>,
Hans Bezemer <the.beez.speaks@gmail.com> wrote:

4tH has supported nested definitions since its inception. But - agreed -
it doesn't have a dictionary, which makes the whole thing a lot easier.

You see, the 4tH ":" word dumps a location and a reference on the
control stack - and compiles a BRANCH. Any nested definition does the
same thing. ":NONAME" compiles a location as a literal and then does the
same thing as ":".

ciforth does approximately the same thing. A dictionary and wordlists
doesnot make this difficult. However an anonymous definition is
bracketed with { } . :NONAME ending with a semi colon is a mistake.

Like I said, in 4tH it isn't a problem. It gets the reference and the
address from the control stack, compiles an EXIT, patches the BRANCH instruction at that address to after the EXIT - and we're done. More
colons than semicolons? That's an imbalance and it stops.

The only time semi-colons posed a problem to me was not in the compiler,
but the :MACRO definitions in the preprocessor, which were terminated by
a semi-colon. I needed the back quote expressions to flag tokens which
may *NOT* be interpreted within a macro definition. Like ` ;` :-)

But I support [: and ;] as well if I really need to write portable code.

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

From Newsgroup: comp.lang.forth

On 11-04-2026 03:54, dxf wrote:

It's an old problem - something that ought not be required, yet appears to fill a need. In addition to VALUE, I have INTEGER (aka 0 VALUE). Thus far I've not tired of it. Sometimes I could use 2VALUE in an app but have resisted the urge. The occasions are simply too few to warrant. I provide definitions for 2VALUE 2TO FVALUE FTO should a user really, really, want them.

That's *EXACTLY* how I feel! ;-)

HB

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.forth

On 24-04-2026 19:36, Paul Rubin wrote:

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

Using Forth means being resourceful. Not to choose the most convenient
and lazy solution imaginable.

Stack allocation is efficient because stack storage is released when the function returns. Global variables instead occupy storage even when the function isn't in use. And, implementing an extra stack under the interpreter is both extra contortions and extra overhead.

C'mon! You can recite those when they're waking you up in the middle of
the night!

I do remember writing some words a while ago to implement multiple
stacks, so there are reasons to want those sometimes.

If you're missing them, here they are:

: 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)

"Resourceful"
sounds more like "masochistic" here.

It may require some additional intellectual effort. But note there are
people enjoying solving a sukodu - and there is no obvious benefit in
doing those at all - contrary to doing Forth.

I thought the idea was to do the
straightforward thing.

No, wrong idea. Try another one :-)

Hans Bezemer

--- Synchronet 3.22a-Linux NewsLink 1.2