Proposal: [129] NAME>INTERPRET wording
This proposal has been moved into this section. Its former address was: /standard/tools/NAMEtoINTERPRET
This page is dedicated to discussing this specific proposal
ContributeContributions
ruv
[129] NAME>INTERPRET wordingProposal2020-02-20 09:55:14
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.
ruv
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.
AntonErtl
I have drafted Proposal: Reword the term "execution token (latest version) to address the execution token issue.
The interpretation semantics of a STATE-dependent immediate word is STATE-dependent. It is trivial for NAME>INTERPRET to return that. In a classic single-xt+immediate-flag system NAME>INTERPRET will never return 0. 0 allows systems with compile-only flags where the text interpreter produces an error when it encounters such a word in interpretation state (e.g., gforth-0.7).
Your proposed change makes no sense; on the usage side, it would mean that a text interpreter that uses FIND-NAME and NAME>INTERPRET is not guaranteed to work. On the implementation side, NAME>INTERPRET does not know whether a word is STATE-dependent, so it cannot return 0 for such words anyway.