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

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.