Digest #87 2019-10-09
Contributions
It is an alternative proposal to the one from Anton.
Problem
The existing specification of FIND is unclear how the returned xt is connected with interpretation and compilation semantics for the corresponding word.
In some popular Forth systems n=1 does not mean that the word is immediate.
Solution
Use the new wording in the specification for FIND.
Keep the original immediacy notion, but use another (more loose) wording for meaning of n in compilation state. The new wording allows to implement the words with undefined execution semantics as "dual-xt" words, and still allows (as it was before) to implement them as immediate STATE-dependent words. Also it allows to have the special definitions to compile the words with undefined interpretation semantics and defined execution semantics (like EXIT), and return proper values for them from FIND.
No need to mention that FIND may return c-addr 0 for the words with undefined interpretation semantics. It is a consequence of the clause that the returned values depend on STATE, and it is mentioned in the Rationale.
Don't change 4.1.2. Perhaps make FIND tighter later when it will be optional. The original specification guarantees that a user-defined text interpreter can interpret all ordinary and user-defined words at least.
Now many Forth systems don't use FIND by themselves but provide it for the old-fashion programs only. There is no much sense to restrict the implementation options of the modern Forth systems for the sake of the outdated approach. I think the modern Forth systems will tend to use Recognizer/Resolver approach for the special syntaxes and special words.
Proposal
Replace the text in the specification of FIND with the following.
( c-addr -- c-addr 0 | xt n )
Find the definition name whose name matches the counted string at c-addr. If the definition is not found, return c-addr and zero. Otherwise the definition is found, xt is the execution token for name, and n is 1 or -1. The all returned values may differ between interpretation and compilation state.
When the definition is found in interpretation state: if the definition is immediate then n is 1, otherwise n is -1; performing xt in intepretation state performs the interpretation semantics for name.
When the definition is found in compilation state: if n is -1, appending the semantics identified by xt to the current definition performs the compilation semantics for name, otherwise performing xt in compilation state performs the compilation semantics for name.
"Performing xt" means performing the execution semantics identified by the execution token xt.
Please check the gist at github for updating and corrections in this proposal.
Replies
This approach has the following issue with libraries.
A library can use upper-case names just as its own or just an old-fashioned style. And as a Forth system is not obligated to support lower-case access for the non-standard words, a program is compelled to use upper-case access to the words from such library.
A possible solution for a standard program is to create the lower-case synonyms automatically for all the new upper-case words after including such library.
Perhaps a better approach is to provide for a program a standard ability to explicitly control (turn on or turn off) lower-case access to the new upper-case words (in ASCII charset only).