Digest #93 2020-02-21
Contributions
Connection of xt with interpretation semantics
The spec says that "xt represents the interpretation semantics of the word nt". But by 2.1 Definitions of terms, execution token (xt) identifies not interpretation semantics but execution semantics.
Solution
Use a wording that is slightly better harmonized with the terms definitions.
The execution token xt identifies the execution semantics that performs the interpretation semantics for the word identified by the name token nt.
Meaning of 0
It seems that the spec implies that if NAME>INTERPRET returns 0 then interpretation semantics is undefined for the corresponding word (by the premise: a specification should describe all possible variants; and the variant is only one in this case).
But actually, in some cases a Forth system just cannot provide an xt that performs the defined interpretation semantics for the corresponding word. Particularly, we can have this case when a "dual semantics" word is implemented as a STATE-dependent immediate word. Technically it is possible to return an xt (e.g. via generation of the corresponding definition on the fly), but a Forth system authors may choose to not implement such functionality.
NB: it is incorrect to return an xt that identifies STATE-depended execution semantics, when the interpretation semantics for the corresponding word don't specified as STATE-depended. Perhaps the NAME> ( nt -- xt|0 ) word from Forth-83 experimental proposals can be standardized to cover such cases. This word should return xt that identifies the execution semantics for the word identified by nt.
Solution
Explicitly mention the second meaning of 0.
If
NAME>INTERPRETreturns 0 then either interpretation semantics is undefined for the word identified by nt, or the system cannot provide an xt that preforms the defined interpretation semantics for this word.
Replies
referenceImplementation - sample implementation that can also be interpreted
The original reference implementation does not have the mentioned issue, — it may work when interpreting.
You mean the ambiguous condition "interpreting a word with undefined interpretation semantics", but during interpretation of WITHIN word, the >R and R> words are not interpreted, since they names are not encountered by the text interpreter. Therefore, this ambiguous condition isn't met.
Moreover, during interpretation of WITHIN, it does not matter whether interpretation semantics of any other word is defined by the standard or not.
See also the terms definitions for "interpretation semantics" and "compilation semantics".
It is important to add that creating and "smudging" a dictionary entry by Colon ":" is only one of several possible ways of implementing the requirements. All these details, such as a dictionary entry and smudging, are under the hood and not available for a standard program.
Without updating the meaning of returned 0 for NAME>INTERPRET, the only option for a Forth system that cannot, in some case, provide xt that performs the corresponding interpretation semantics, is to don't provide NAME>INTERPRET word at all.