From Newsgroup: comp.lang.forth

On 6/7/26 8:31 AM, Ruvim wrote:

On 2026-06-07 11:53, Stephen Pelc wrote:

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.

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

1 value v1
2 value v2 immediate
: test-a to v2 v1-a ;
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.

The test depends on being able to define V2 as IMMEDIATE.

In a standard Forth system, a child of `value`, as well as *any* user- defined named definition (with the exception of `synonym` children), can
be made immediate. A child of synonym inherits immediacy from its
original word.

<https://forth-standard.org/standard/core/IMMEDIATE>

In zeptoforth at least there is no way to define new immediate words
other than colon definitions for the reason that [IMMEDIATE] needs to
be called (or IMMEDIATE needs to be called from within a defining word)
before ; is called because zeptoforth is designed to be capable of
compiling to flash, and once words are written to flash they are written
to flash and they cannot be mutated afterwards (aside from mass flash
erasure).

New words to specifically create immediate CONSTANT's or like could be
created but I have never had the need to do so; if someone needs an
immediate CONSTANT they could use the following:

: CONSTANT-IMMEDIATE { x }
: IMMEDIATE X POSTPONE LITERAL POSTPONE ;
;
: 2CONSTANT-IMMEDIATE { x y }
: IMMEDIATE X POSTPONE LITERAL Y POSTPONE LITERAL POSTPONE ;
;

Of course, zeptoforth is not a standard Forth system, and for the most
part does not attempt to be one.

Where in the standard does it specify that children on VALUE are not
IMMEDIATE ?

It is specified in the glossary entry 6.2.2405 VALUE <https://forth-standard.org/standard/core/VALUE>

Namely, it specifies "_name_ Execution", where _name_ is a child of
`value`. And it does not specify the compilation semantics in
"Compilation:" section.

Therefore, we apply 3.4.3.3 Compilation semantics: <https://forth-standard.org/standard/usage#usage:compile>

-a | Unless otherwise specified in a "Compilation:" section
-a | of the glossary entry, the compilation semantics
-a | of a Forth definition shall be to append
-a | its execution semantics to the execution semantics
-a | of the current definition.

Thus, a word created by `value` is not an immediate word unless the user applies `immediate` to it.

This does not prevent us from performing any optimizations when adding
the execution semantics of a `value` child to the current definition.

If I made a way to make immediate VALUE's or 2VALUE's in zeptoforth
(e.g. I created a word VALUE-IMMEDIATE), I would expect the following behavior:

1 VALUE FOO
2 VALUE-IMMEDIATE BAR
: FOOBAR 3 TO BAR FOO ; \ This is cromulent
FOO . \ prints 1 ok
BAR . \ prints 2 ok
FOOBAR . \ prints 1 ok
FOO . \ prints 1 ok
BAR . \ prints 3 ok

If does so specify, then the test is implementation dependent,
and contradicts the intention of the standard.

Be careful what you wish for.

VFX and its predecessor ProForth have used a flagging TO for well over 30
years and I am not breaking the world's largest Forth application
(32 bit, over 30 Mb binary) for a language lawyer and a probably
invalid test.

I would like to check whether such a change in `to` and `value` will
brake this application.

In any case, nothing prevents VfxForth from providing such a `value`
word whose children cannot be made immediate. However, this should be documented, without passing off such a `value` as a standard word.

Ditto for the provided word `to`, which is not a parsing word (whereas
the standard `to` is required to perform parsing).

In my own case I implement TO as a parsing word. TO parses a token, then
first looks up in the local variable stack whether the token is a local variable (provided a compiling state), and then compiles code to pop the
TOS (and that directly below it if the local variable is double-cell)
and set that local variable to that. If no such local variable is
available within the current local scope, then it attempts to find a
word with that same name. If a word exists, and it is a valid VALUE or
2VALUE, it then compiles code to pop the TOS (and that directly below it
if it is a 2VALUE) and set the VALUE or 2VALUE's compiled location in
RAM to it.

Travis
--- Synchronet 3.22a-Linux NewsLink 1.2