,---------------. | Contributions | `---------------´ ,------------------------------------------ | 2024-09-25 18:35:27 ruv wrote: | proposal - Incorrect use of semantics terms | see: https://forth-standard.org/proposals/incorrect-use-of-semantics-terms#contribution-365 `------------------------------------------ ## Author Ruv ## Change Log - 2024-09-25 Initial revision ## Problem The section [2.1 Definitions of terms](https://forth-standard.org/standard/notation#notation:terms) gives the following definitions: - **interpretation semantics**:The behavior of a Forth definition when its name is encountered by the text interpreter in interpretation state. - **compilation semantics**: The behavior of a Forth definition when its name is encountered by the text interpreter in compilation state. These definitions are very good. Essentially, they talk about *observable* behavior, behavior that the Forth system exhibits under the specified conditions (namely, the word name is encountered in *interpretation state* or the word name is encountered in *compilation state*) and that a standard program or user can detect. Note that if some effect cannot be detected under the specified conditions, than this effect is not a part of the corresponding semantics, and if some effect is a part of semantics, it can be detected under the corresponding conditions. Almost in all cases when these terms are used in the normative parts, they are used correctly. **The problem is that in a few places these terms are used incorrectly.** This produces inconsistency, confusing, many questions and disputes. There are two places where they are used incorrectly: - about default interpretation semantics, - about compilation semantics of an immediate word. ### About default interpretation semantics The section [3.4.3.2 Interpretation semantics](https://forth-standard.org/standard/usage#usage:interpret) says: - Unless otherwise specified in an "Interpretation:" section of the glossary entry, the interpretation semantics of a Forth definition are its execution semantics. We can create a word whose execution semantics, when performed in *compilation state*, exhibit effects that cannot be detected when the name of this word is encountered by the Forth text interpreter in *interpretation state*. It means, these effects are not a part of the interpretation semantics for this word. Thus, the interpretation semantics for this word **are not** the execution semantics of this word. An example: ```forth : foo1 ( -- 1 | ) s" 1" evaluate ; ``` When the execution semantics of `foo1` are performed in *compilation state*, something is appended to the current definition. This effect is not a part of the interpretation semantics of this word. Thus, the interpretation semantics of this word are not the execution semantics of this word . This is an inconsistency (if not a conflict) in terminology. #### Discussion There is a point of view that the section 3.4.3.2 defines a different meaning for the term "interpretation semantics" for the case when "Interpretation" section is absent. But this is not true. Every term is defined separately and explicitly. In this section the term "interpretation semantics" **is used** rather than defined. ### About compilation semantics for an immediate word The section [2.1 Definitions of terms](https://forth-standard.org/standard/notation#notation:terms) says: - **immediate word**: A Forth word whose compilation semantics are to perform its execution semantics. This definition does not say that the execution semantics shall be performed in *compilation state*. It means, they can be performed in *interpretation state* too. But we can create a word whose execution semantics, when performed in *interpretation state*, exhibit effects that cannot be detected when the name of this word is encountered by the Forth text interpreter in *compilation state*. It means, these effects are not a part of the compilation semantics of this word. Thus, the compilation semantics of this word **are not** to perform the execution semantics of this word (regardless the state). An example: ```forth : foo2 ( -- 2 | ) s" 2" evaluate ; immediate ``` When the execution semantics of `foo2` are performed in *interpretation state*, the number `2` is placed on the data stack. This effect is not a part of the compilation semantics of this word. Thus, the compilation semantics of this word **are not** to perform the execution semantics of this word. Again, this is an inconsistency (if not a conflict) in terminology. #### Discussion There is a point of view that the definition for the term "immediate word" also defines another meaning for the term "compilation semantics", that applies to immediate words only. But this not true. Because every term is defined separately and explicitly. In this definition the term "compilation semantics" **is used** rather than defined. ## Solution Change wording in the mentioned cases in such a way that the "interpretation semantics" and "compilation semantics" terms are used correctly: - Unless otherwise specified in an "Interpretation:" section of the glossary entry, the interpretation semantics of a Forth definition are to perform its execution semantics in interpretation state. - **immediate word**: A Forth word whose compilation semantics are to perform its execution semantics in compilation state. ## Proposal In the section [3.4.3.2 Interpretation semantics](https://forth-standard.org/standard/usage#usage:interpret), replace the sentence: > Unless otherwise specified in an "Interpretation:" section of the glossary entry, the interpretation semantics of a Forth definition are its execution semantics. with the sentence: > Unless otherwise specified in an "Interpretation:" section of the glossary entry, the interpretation semantics of a Forth definition are to perform its execution semantics in interpretation state. In the section [2.1 Definitions of terms](https://forth-standard.org/standard/notation#notation:terms), replace the sentence: > **immediate word**: A Forth word whose compilation semantics are to perform its execution semantics. with the sentence: > **immediate word**: A Forth word whose compilation semantics are to perform its execution semantics in compilation state. ## Consequences The inconsistency in the term "immediate word" was used to argue that the word `POSTPONE`, when applied to an immediate word, shall append the execution semantics of the word to the current definition, because they are allegedly always equivalent to the compilation semantics of the word. This inconsistency cannot be used anymore. If a Forth system provides the word `POSTPONE`, which when applied to an immediate word appends the execution semantics of the word to the current definition, this perhaps adds an environmental restriction to the Forth system. On the other hands, it is easy to implement `POSTPONE` correctly: ```forth [undefined] lit, [if] : lit, ( x -- ) postpone literal ; [then] : compilation ( -- flag ) state @ 0<> ; : enter-compilation ( -- ) ] ; : leave-compilation ( -- ) postpone [ ; : execute-compiling ( i*x xt -- j*x ) compilation if execute exit then enter-compilation execute leave-compilation ; : postpone ( "name" -- ) parse-name find-name dup 0= -13 and throw name>compile ( x xt.compiler ) compilation if swap lit, lit, ['] execute-compiling compile, exit then execute-compiling ; immediate ``` (see other variants in my [post](https://github.com/ForthHub/discussion/discussions/103#user-content-solution) at ForthHub) ,---------. | Replies | `---------´ ,------------------------------------------ | 2024-09-24 11:06:57 ruv replies: | requestClarification - How to perform the interpretation semantics for a word | see: https://forth-standard.org/standard/tools/NAMEtoINTERPRET#reply-1307 `------------------------------------------ ### Classic single-xt approach In the classic single-xt approach, a Forth system defines execution semantics for every word, and these semantics are identified by an execution token (_xt_) that is associated with the word. So, in the classic single-xt approach, to perform the *observable interpretation semantics* of a word we should perform its execution semantics in interpretation state. To perform the *observable interpretation semantics* of a word **regardless of the current state**, we should: - if the system is in interpretation state: perform the execution semantics; - if the system is in compilation state: leave compilation state (i.e., enter compilation state), perform the execution semantics, enter compilation state. Similar, to perform the *observable compilation semantics* of a word **regardless of the current state**, we should: - if the system is in compilation state: perform the execution semantics; - if the system is in interpretation state: enter compilation state, perform the execution semantics, leave compilation state (i.e., enter interpretation state). To perform for a word the *observable interpretation semantics* if the Forth system in interpretation state, and the *observable compilation semantics* if the Forth system in compilation state we should simply perform the execution semantics of the word. ### Any standard system At first glance, one might think that to perform the *observable interpretation semantics* for a word **regardless of the state** it is sufficient to simply execute the _xt_ returned by `name>interpret` for the word's _nt_. But this is not true on most Forth systems. Some examples: ```forth : test1 ( -- flag ) state @ 0<> ; : test2 ( -- -1 | ) s" true" evaluate ; ``` These words are ordinary words, which are defined by specifying their execution semantics. Note that in both cases the execution semantics depends on the system's state. The *observable interpretation semantics* of `test1` are to place `0` on the data stack. The *observable interpretation semantics* of `test2` are to find the word "`true`" and perform its interpretation semantics, that are (in a standard system) to place `-1` on the data stack, and if the word is not found, throw exception -13. On most Forth systems, executing of the _xt_ returned by `name>interpret` for these words produces different results depending on the state. Thus, to perform the *observable interpretation semantics* for these words, we should execute an _xt_ returned by `name>interpret` in **interpretation state** only. ### What `name>interpret` returns **If we admit** that the above behavior of `name>interpret` is desired, then there are no difference with the single-xt approach: in **the general case**, we should set interpretation state to perform the *observable interpretation semantics* for a word (see the steps in the section "Classic single-xt approach" above). Consequently, we can admit that `name>interpret` always returns an _xt_ that identifies the execution semantics of the word, because: 1. it is true for any user-defined word (except synonyms for standard words that are considered the same as the corresponding standard words); 2. it is true for ordinary standard words; 3. it is true for immediate standard words; 4. it is true in the cases when special interpretation semantics are defined for a standard word, because the execution semantics are not defined in these cases, thus, a returned _xt_ can be considered as an identifier for the **system-dependent execution semantics** of the word, but executing of this _xt_ in interpretation state shall exhibit the *observable interpretation semantics* for the word, which are specified by the standard; 5. it is true in the cases when interpretation semantics are undefined for a standard word, because obtaining the execution token of the word is ambiguous (at the moment), and so a returned _xt_ can be considered as an identifier for the **system-dependent execution semantics** of the word, but executing of this _xt_ in interpretation state shall exhibit the *observable interpretation semantics* for the word, which are system-defined. There are no other cases. This applies to single-xt systems as well as to dual-xt systems. ### Standard language In all cases when special interpretation semantics or special compilation semantics are defined for a standard word, they are *observable interpretation semantics* or *observable compilation semantics* for the word correspondingly — and this is as it must be, unless we want to impose a particular implementation. Also, by the definitions, the Forth text interpreter performs the *observable interpretation semantics* for the word when in interpretation state, and the *observable compilation semantics* for the word when in compilation state. There are only few places in the normative parts of the standard where a reader can be confused whether *observable* semantics are meant or something else. For example, in [3.4.3.2 Interpretation semantics](https://forth-standard.org/standard/usage#usage:interpret): "unless otherwise specified [...], the interpretation semantics of a Forth definition are its execution semantics". Obviously, in this case it is not about *observable interpretation semantics*. The *observable interpretation semantics* in this case are to perform the execution semantics in interpretation state. I think, that is an omission — that item should describe *observable interpretation semantics*. So, in few places the term *interpretation semantics* does not mean *observable interpretation semantics*, whereas in most cases this term means *observable interpretation semantics*. This is an inconsistency that produces many problems. I think, the wording should be adjusted so that everywhere the term *interpretation semantics* means *observable interpretation semantics*. Similar for "compilation semantics". This will eliminate some confusing, many questions and disputes. ,------------------------------------------ | 2024-09-24 12:42:54 ruv replies: | requestClarification - How to perform the interpretation semantics for a word | see: https://forth-standard.org/standard/tools/NAMEtoINTERPRET#reply-1308 `------------------------------------------ There is a typo in my above [post](https://forth-standard.org/standard/tools/NAMEtoINTERPRET#reply-1307), in the section "Classic single-xt approach": > if the system is in compilation state: leave compilation state (i.e., enter compilationinterpretation state), perform the execution semantics, enter compilation state. ----- I plan to refactor and/or update some my proposals once we reach consensus on this topic (if any). Among them: - [[129] `NAME>INTERPRET` wording](https://forth-standard.org/proposals/name-interpret-wording?hideDiff#reply-1110) - [[122] Clarify `FIND`, more classic approach](https://forth-standard.org/proposals/clarify-find-more-classic-approach?hideDiff#reply-682) - [[163] Tick and undefined execution semantics](https://forth-standard.org/proposals/tick-and-undefined-execution-semantics?hideDiff#contribution-163) - [[251] Clarification for execution token](https://forth-standard.org/proposals/clarification-for-execution-token?hideDiff#reply-1098) - [[249] Revert rewording the term "execution token"](https://forth-standard.org/proposals/revert-rewording-the-term-execution-token-?hideDiff#contribution-249) - [[292] Update rationale for `SLITERAL`](https://forth-standard.org/proposals/update-rationale-for-sliteral?hideDiff#reply-1003) ,------------------------------------------ | 2024-09-25 12:44:48 BerndPaysan replies: | requestClarification - How to perform the interpretation semantics for a word | see: https://forth-standard.org/standard/tools/NAMEtoINTERPRET#reply-1309 `------------------------------------------ The compilation semantics is more complicated: If the word is immediate, compilation semantics in the single-xt system is to execute the word in compilation state; if it is non-immediate, it is `COMPILE,` the word. The information whether the word is immediate is not part of the xt. Therefore, the more interesting part is `NAME>COMPILE`, which converts a name token to a tuple on the stack which can be executed to get the compilation semantics. There's still the need on single-xt systems to be in compilation state, as the immediate word could be state-smart. As current pre-1.0-Gforth shows, you can have an xt as single identifier for a word and executing that xt always gives you the interpretation semantics; in the case that there is some other compilation semantics, `NAME>COMPILE` replaces that xt with another one. What we might need instead of `NAME>INTERPRET EXECUTE` and `NAME>COMPILE EXEUCTE` might be a word like `COMPILE-XT`, which does whatever is needed to get the compilation semantics of a word. It's not the same as `COMPILE,`. ,------------------------------------------ | 2024-09-25 13:33:10 UlrichHoffmann replies: | proposal - Better wording for "data field" term | see: https://forth-standard.org/proposals/better-wording-for-data-field-term#reply-1310 `------------------------------------------ ## Author Ruv ## Change Log 2022-09-16 On the TC meeting it was suggested to retain referencing of `CREATE`. It's acceptable to the author at the moment. 2021-09-14 Initial version ## Assumption A basic term definition should not inalienably refer to a Forth word or a further section of the standard. Such referring means that there is a lack of terms and the terminology should be better developed, or that just this definition is too poor. ## Problem We have the following problems with the definition for the "data field" term: 1. It inalienably refers to the [`CREATE`](https://forth-standard.org/standard/core/CREATE) word ( Forth-2012 contains only one such definition in the section [2.1. Definitions of terms](https://forth-standard.org/standard/notation#section.2.1)). 2. Formally, it conflicts with the term "data space". It says that a data field is a data space (i.e., it is a hyponym of). But the data space is a singleton, it unites all memory regions that may be accessed by a program. Hence a data field cannot be a hyponym of (or an instance of) the data space. 3. It connects a data field to a word defined via `CREATE`. But a sophisticated `SYNONYM` can keep these association for the newname (and the new xt) too. So, there is no need to restrict this association by `CREATE` in the term definition. 4. Formally, it conflicts with the term "word", since this term is used in a non normative meaning in this definition. ## Solution Update the definition for the "data field" term with the following changes: - Remove the reference to `CREATE`. - Say that a data field is a data space _region_ (as it actually is). - Use the term "Forth definition" instead of the term "word" (optionally). The insertion and deletions: > **data field**: The A data space region associated with a word defined via CREATE a Forth definition. or another variant: > **data field**: The A data space region associated with a Forth word defined via CREATE. or yet another one: > **data field**: The A data space region associated with a Forth word defined via CREATE. ## Rationale It doesn't matter whether each Forth definition is associated with a data field, or not (in some system, each Forth definition is associated with a data field, but some of them have zero size). In anyway, at the moment, the standard provides an API to associate a data field to and obtain it for a word that is created via `CREATE` only. But this can be changed in the future, and now without touch the basic terms. The expression "data space region" is obvious, so there is no need to define it. Also, it's already used in other places (e.g., see "region of data space" in the "variable" term). Concerning "word" and "Forth definition". The latter one is more correct in this case. Although, this change is optional. The definition for the "word" term can be independently updated too, since it's used in the sense "named Forth definition" in many places (see also another [comment](https://forth-standard.org/standard/tools#reply-296)). Perhaps a better way is to formally associate a data field with an execution token, as it actually is (see [`>BODY`](https://forth-standard.org/standard/core/toBODY)). But, since the expression "_name's_ data field" is used in some glossary entries, this approach requires an additional term: - **data field of a Forth definition**: the data field associated with the execution token of the Forth definition. This proposal can be updated accordingly, if any. ## Proposal Replace the definition for the "data field" term (in the [section 2.1](https://forth-standard.org/standard/notation#section.2.1)) by the following: > A data space region associated with a Forth word defined by CREATE (6.1.1000) ,------------------------------------------ | 2024-09-25 14:01:30 ruv replies: | requestClarification - How to perform the interpretation semantics for a word | see: https://forth-standard.org/standard/tools/NAMEtoINTERPRET#reply-1311 `------------------------------------------ > The compilation semantics is more complicated: If the word is immediate, compilation semantics in the single-xt system is to execute the word in compilation state; if it is non-immediate, it is `COMPILE,` the word. Sure. It's an oversight that I wrote the part about only the immediate words, and did not make any note about htat (I thought only about the case of unusual words at that moment). But you get the idea. ----- > What we might need instead of `NAME>INTERPRET EXECUTE` and `NAME>COMPILE EXEUCTE` might be a word like `COMPILE-XT`, which does whatever is needed to get the compilation semantics of a word. It's not the same as `COMPILE,`. Do you mean something like this? ```forth : compile-nt ( i*x nt -- j*x ) name>compile execute \ or \ name>compile execute-compiling \ it's ensures that xt executed in compilation state ; ``` ,------------------------------------------ | 2024-09-25 16:53:09 flaagel replies: | proposal - Relax documentation requirements of Ambiguous Conditions | see: https://forth-standard.org/proposals/relax-documentation-requirements-of-ambiguous-conditions#reply-1312 `------------------------------------------ ,------------------------------------------ | 2024-09-25 16:54:43 BerndPaysan replies: | proposal - Relax documentation requirements of Ambiguous Conditions | see: https://forth-standard.org/proposals/relax-documentation-requirements-of-ambiguous-conditions#reply-1313 `------------------------------------------ I would rather recommend to continue the work to remove ambiguous conditions from the standard, so that words become more predictable. That will also reduce the burden of documentation without making programmers scratch their heads what's going to happen in these cases.