[424] 2026-02-12 09:39:50 EkkehardSkirl wrote:

proposal - Forth Standards, Backward Compatibility and modern `state of the art` words with their `historical traditional` counterparts.

Author:

Ekkehard Skirl

Change Log:

• 2026-02-12 10-05 CET: Initial proposal
• 2026-02-12 07-07 CET: Created as working draft

Problem:

For not longtime involved users the standard may look a little bit confusing. Especially the existence of modern state of the art words and their historical traditional counterparts hard to find out. This is caused by the kind of backward compatibility the standard committee is practising but could be more clearly handled in the standards.

P.S. All this is the result of my current personal experience with and understanding of the standard and forth systems. So maybe I am wrong and this is not a problem at all. But I think it is worth to be discussed and maybe improved.

Solution:

Creating backward compatibility word sets and move the historical traditional words to there, if modern state of the art word pendants exist.

So the now existing word sets deal with the state of the art words only.

If a forth system claims to be forth standard XY conform the backward compatibility VW word sets may be absent. But if it claims to be forth standard VW conform too it has to provide the fitting backward compatibility word sets additional.

If a forth program is for instance forth standard XY conform and wants to run on a less standard system it could add the words of the fitting backward compatibility word sets to the system and shall run.

Thus the standard shall provide wrapping definitions for the historical traditional words as adapters using the modern state of the art words. These wrappers shall exist as one possible solution proposal and shall not claim to be the best solution in any situation.

So my proposal is to have two backward compatibility word sets for the 1994 and the 2012 standards called STANDARD94 and STANDARD2012.

One advantage is, too, to make it more clear and easy to give words better and more speechable names from standard to standard providing their historical traditional names as aliases inside the backward compatibility word sets.

This concept offers additional the possibility of having words with the same useful names with different state of the art definitions. But maybe this brings more problems than it gives a positive effort.

Typical use:

Many of the historical traditional words can be reconstructed using the more modern state of the art words to demonstrate flexibility and implementation possibilities. So here are some examples.

Comparison of Traditional and Modern Standard Words

Category	Classic Word (Legacy)	Modern Word (Forth 2012)	Advantage of the Modern Variant
Parsing	WORD	PARSE-NAME	Returns addr u; no need to copy to the HERE buffer.
Dictionary	FIND	FIND-NAME (or SEARCH-WORDLIST)	Returns a name token (nt) instead of an xt with a flag; cleaner.
Introspection	>NAME and >BODY	NAME>XT and NAME>INTERPRET	Works with tokens instead of direct address offsets.
Header Data	ID. (Prints Name)	NAME>STRING (then TYPE)	Separates name finding from output.
Word Lists	CONTEXT and CURRENT	GET-ORDER and SET-CURRENT	Supports multiple word lists (namespaces) more cleanly.
Compilation	[COMPILE]	POSTPONE	POSTPONE is smarter and replaces almost all special cases.
Memory	ALLOT	ALIGN and ALLOCATE	Improved support for data alignment in RAM.

Dictionary Search: FIND vs. FIND-NAME

FIND is a traditional term that searches directly in the dictionary. It could be replaced by a combination of more modern terms like SEARCH-WORDLIST and NAME>XT to achieve the same functionality.

The old FIND is notorious for its "odd" return value (-1, 0, 1) and because it expects a counted string.

Code snippet for FIND using more modern terms:

: FIND ( c-addr -- c-addr 0 | xt 1 | xt -1 )
    DUP COUNT FIND-NAME ( c-addr nt|0 )
    DUP 0= IF EXIT THEN \ Not Found
    NIP \ c-addr removed
    DUP NAME>XT SWAP \ fetch xt, then check nt
    NAME-IMMEDIATE? IF 1 ELSE -1 THEN ;

Dictionary Manipulation: LATEST vs. GET-CURRENT

Previously, LATEST was a variable that could be easily read using @. However, this assumes there is only one word list. In modern systems with multiple word lists (e.g., for different modules or libraries), GET-CURRENT is a function that returns the ID of the current word list, which is more flexible and clearer.

Code snippet for LATEST with GET-CURRENT:

: LATEST ( -- addr )
    GET-CURRENT ; \ Returns the ID, which is functionally equivalent to LATEST

Name Strings: WORD vs. PARSE-NAME

WORD writes the result to a fixed buffer (HERE), which often leads to problems when reading the next word and overwriting the previous one. PARSE-NAME, on the other hand, directly returns the address and length of the word in the input buffer (TIB) without making a copy, which is more efficient and safer.

Code snippet for WORD with more modern words:

: WORD ( char -- c-addr )
    PARSE HERE ( addr len ) \ Reads up to the delimiter after HERE
    \ (The length byte logic of WORD would need to be added here)
;

Proposal:

See Solution:.

TBD.

Reference implementation:

Not applicable or TBD.

Testing: (Optional)

Not applicable.

[r1616] 2026-02-10 10:36:07 EkkehardSkirl replies:

proposal - Recognizer committee proposal 2025-09-11

Remarks on: Solution

• List of five usage level - Level 2:

  • We should use to name 'recognizer sequences' consequently recs-xxx to name recognizer sequensces and rec-xxx to name recognizers. So 'rec-forth' should be 'recs-forth' (Naming)

• List of five usage level - Level 3:

  • On the first glance I was confused abaut the suddenly appearing 'translation token', since the preamble talked only about 'translation'. So it could be more clear to append a partial sentence to 'The result of the matching recognizer is a translation, an on-stack representation of the word or literal.' like 'The result of the matching recognizer is a translation, an on-stack representation of the word or literal, consistimng of a translation token and possibly additional data.'

  • The currently proposed names of the translation token tell me, that there is an action, but it is a kind of type. So they should called more readable 'translation-XXX' and since we use the short 'rec' for 'recognizer' it is consquently to call them shorter, for instance 'trl-XXX' (Naming)

Remarks on: Proposal:

Usage requirements:

Translations and text-interpretation

The second paragraph sounds a little bit confusing to me.

'All the proposed-standard translate-... words only push a translation token, and that stack effect is given, but in addition the definitions of these words also show a "Stack effect to produce a translation"; ...'

May be this confusion is based on my less knowledge of the english common speech.

But why should a word push a 'stack effect' or an information about existing stack effects, with what a kind of purpose? This translation tokens are identifier to know about which recognizer accepted the given string token and I think used to compare. And of course, the documentation of the recognizer that produces this token must document this stack effects?

This text may be written as poposed here:

'All the proposed-standard translate-... words only push a translation token. In addition the definitions of these words shall also contain a "Stack effect to produce a translation" (for instance as a comment in its colon definition); ... '

[r1617] 2026-02-10 22:36:05 AntonErtl replies:

proposal - Recognizer committee proposal 2025-09-11

Tests

I did not want to repost everything just to post the current status of the tests, so here they are just as a reply:

You can find tests here. As they currently are, they work on Gforth, but there seems to be a bug in either the tests or in Gforth that appears when you uncomment one or both of the commented-out tests (search for \ t{).

[r1618] 2026-02-12 23:44:32 AntonErtl replies:

proposal - Recognizer committee proposal 2025-09-11

You can now find the reference implementation here. It has been implemented from scratch with very little input from Gforth's implementation. It runs on Gforth (and uses a few Gforth-specific words explained in the comments) and tests fine on the tests that have not been commented out (and produces the same failures as Gforth's recognizer implementation when one uncomments these lines.

You can also find the tests here.