Proposal:  Clarification for execution token
This page is dedicated to discussing this specific proposal
ruv  Clarification for execution tokenProposal2022-08-13 20:16:29
- 2022-08-13 Initial version
2022-08-12 Revert rewording the term "execution token" (proposal).
2021-09-08 Reword the term "execution token" (the accepted version).
2020-02-20 Pointing out a problem in NAME>INTERPRET wording
By the definition of the term "execution token" in Forth-94 and Forth-2012, it's a value that identifies execution semantics. Can such value identify other behavior, e.g. some interpretation semantics or compilation semantics? It's unclear at the first glance.
Actually, an execution token can identify other semantics too, but only if they are equivalent to the execution semantics that this token identifies.
It is so because for any execution token there exists at least one named or unnamed Forth definition the execution semantics of which are identified by this execution token. So, in any case, an execution token always identifies some execution semantics, but accidentally these semantics can be equivalent to some interpretation semantics, or some compilation semantics, and then it identifies them too. It's unnecessary that they connected to the same Forth definition. Also, consequently, it's impossible that an execution token identifies some compilation semantics, or some interpretation semantics, but doesn't identify the equivalent execution semantics.
To solve the initial problem we can state these basics explicitly in a normative part.
: foo postpone if ; :noname postpone if ; ( xt )
The execution semantics for
foo are equivalent to the compilation semantics for
xt that is left on the stack identifies the execution semantics for an anonymous Forth definition, and these semantics are equivalent to the compilation semantics for
When an execution token is intended to perform the interpretation semantics or compilation semantics for a word, the execution semantics that this token identifies should be also described to avoid ambiguity.
Example of wrong use:
- xt identifies the interpretation semantics of the word X.
Example of right use:
- The execution semantics identified by xt are equivalent to the interpretation semantics of the word X.
- Performing the execution semantics identified by xt in interpretation state performs the interpretation semantics of the word X.
- Executing xt in interpretation state performs the interpretation semantics of the word X.
Actually, the standard contains only three places where the "execution token" notion is used ambiguously — the glossary entries for
NAME>COMPILE. These entries have not only this but also some other problems, so they should be corrected anyway. The corresponding proposals are also in progress already.
Add into beginning of the section 22.214.171.124 Execution tokens the following paragraph:
For any execution token there exists at least one Forth definition (named or unnamed) the execution semantics of which are identified by this execution token. The execution semantics identified by an execution token may be equivalent to the interpretation semantics or compilation semantics for some word, or to some run-time semantics.