,---------------. | Contributions | `---------------´ ,------------------------------------------ | 2022-08-13 20:16:29 ruv wrote: | proposal - Clarification for execution token | see: https://forth-standard.org/proposals/clarification-for-execution-token#contribution-251 `------------------------------------------ ## Author Ruv ## Change Log - 2022-08-13 Initial version ### Preceding history - 2022-08-12 [Revert rewording the term "execution token" ](https://forth-standard.org/proposals/revert-rewording-the-term-execution-token-#contribution-249) (proposal). - 2021-09-08 [Reword the term "execution token"](https://forth-standard.org/proposals/reword-the-term-execution-token-?hideDiff#reply-742) (the accepted version). - 2020-09-03 An attempt to solve the problem in [`NAME>INTERPRET`](https://forth-standard.org/standard/tools/NAMEtoINTERPRET) by change meaning of "execution token" — [Reword the term "execution token"](https://forth-standard.org/proposals/reword-the-term-execution-token-?hideDiff#reply-486) - 2020-02-20 Pointing out a problem in [NAME>INTERPRET wording](https://forth-standard.org/proposals/name-interpret-wording) ## Problem 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. ## Solution 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. ### Example ``` : foo postpone if ; :noname postpone if ; ( xt ) ``` The execution semantics for `foo` are equivalent to the compilation semantics for `if`. _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 `if`. ## Typical use 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 [`FIND`](https://forth-standard.org/standard/core/FIND), [`NAME>INTERPRET`](https://forth-standard.org/standard/tools/NAMEtoINTERPRET) and [`NAME>COMPILE`](https://forth-standard.org/standard/tools/NAMEtoCOMPILE). 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. ## Proposal Add into beginning of the section [3.1.3.5 Execution tokens](https://forth-standard.org/standard/usage#subsubsection.3.1.3.5) 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. ,------------------------------------------ | 2022-08-13 23:24:52 ruv wrote: | proposal - Exclude zero from the data types that are identifiers | see: https://forth-standard.org/proposals/exclude-zero-from-the-data-types-that-are-identifiers#contribution-252 `------------------------------------------ ## Author Ruv ## Change Log - 2022-08-14 Initial version ## Problem In many cases it's supposed that a data object cannot be equal to a single-cell value zero, but the corresponding data type allows that. For example - [`NAME>INTERPRET`](https://forth-standard.org/standard/tools/NAMEtoINTERPRET) implies that an execution token cannot be zero. - [`FIND-NAME`](https://forth-standard.org/proposals/find-name?hideDiff#reply-174) implies that a name token cannot be zero. - Usual practice in programs is to assume an address, a file identifier, a word list identifier be a nonzero value. ## Solution Explicitly exclude zero from the address, execution token, name token, word list identifier, file identifier data types. When zero is a valid value on the underlying level, it can be reserved from use, or filtered out in the wrappers over the API routines of the underlying level. Also, fix incorrect wording in the "subtype" definition, since members are not a subject of the subset relationship (it actually operates on sets):
"A data type _i_ is a subtype of type _j_ if and only if the members of _i_ are a subset of the members of _j_". Also, add the missed data type relationships. ## Proposal ### Fix wording for "subtype" In the section [3.1.1 Data-type relationships](https://forth-standard.org/standard/usage#subsection.3.1.1) Replace the phrase: > A data type _i_ is a subtype of type _j_ if and only if the members of _i_ are a subset of the members of _j_. With the phrase: > A data type _i_ is a subtype of type _j_ if and only if each member of _i_ is a members of _j_. ### Notation for difference between sets (relative complement) In the section [3.1.1 Data-type relationships](https://forth-standard.org/standard/usage#subsection.3.1.1), add the following phrase at the end of the first paragraph: > The notation "i \ j" is used to denote "the data type that includes all those and only those members of _i_ which are not members of _j_". ### Exclude zero from the **address** and **execution token** data types In the section [3.1.1 Data-type relationships](https://forth-standard.org/standard/usage#subsection.3.1.1) Replace: > a-addr ? c-addr ? addr ? u ; With: > a-addr ? c-addr ? addr ? u \ {0} ; Replace: > xt ? x; With: > xt ? x \ {0}; ### Exclude zero from the **name token** data type In the end of the section [15.3.1 Data types](https://forth-standard.org/standard/tools#subsection.15.3.1) add the following subsection: > #### 15.3.1.1 Data-type relationships > Add the following to the end of the list of subtype relationships in the section [3.1.1](https://forth-standard.org/standard/usage#subsection.3.1.1) Data-type relationships: > > `nt ? x \ {0};` ### Exclude zero from the **word list identifier** data type In the end of the section [16.3.1 Data types](https://forth-standard.org/standard/search#subsection.16.3.1) add the following subsection: > #### 16.3.1.1 Data-type relationships > Add the following to the end of the list of subtype relationships in the section [3.1.1](https://forth-standard.org/standard/usage#subsection.3.1.1) Data-type relationships: > > `wid ? x \ {0}; ` ### Exclude zero from the **file identifier** data type In the end of the section [11.3.1 Data types](https://forth-standard.org/standard/file#subsection.11.3.1) add the following subsection: > #### 11.3.1.1 Data-type relationships > Add the following to the end of the list of subtype relationships in the section [3.1.1](https://forth-standard.org/standard/usage#subsection.3.1.1) Data-type relationships: > > `fam ? x;`
> `fileid ? x \ {0};`