,---------------. | Contributions | `---------------´ ,------------------------------------------ | 2021-09-14 08:55:49 ruv wrote: | proposal - Better wording for "data field" term | see: https://forth-standard.org/proposals/better-wording-for-data-field-term#contribution-214 `------------------------------------------ ## Author Ruv ## Change Log 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 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 definition. ,---------. | Replies | `---------´ ,------------------------------------------ | 2021-09-12 15:31:01 PeterKnaggs replies: | testcase - Additional test for UTF-16 | see: https://forth-standard.org/standard/core/CComma#reply-768 `------------------------------------------ I don't agree, I use UTF-16 to store a string in memory. My `C,` stores a 16-bit value, so would pass this test without problem. Forth '94 went to some extent to allow UTF-16 which is inherited by Forth '12. ,------------------------------------------ | 2021-09-13 08:55:46 ruv replies: | testcase - Additional test for UTF-16 | see: https://forth-standard.org/standard/core/CComma#reply-769 `------------------------------------------ > I don't agree, I use UTF-16 to store a string in memory. Certainly UTF-16 may be used. But then the char size should be 2 bytes. My point was that it's not allowed to use UTF-16 **when** the char size is 1 byte (and the test will fail in such case). By the same ground, UTF-32 may be used when the char size is 4 bytes only (any other char size will not be compliant). ,------------------------------------------ | 2021-09-13 17:02:04 AntonErtl replies: | proposal - Reword the term "execution token" | see: https://forth-standard.org/proposals/reword-the-term-execution-token-#reply-770 `------------------------------------------ The point of the definition of terms is to paint a broad picture of what these terms mean. Providing a misleading definition is contrary to that point, even if you can argue that the definition is (or at least can be interpreted as) technically correct, and those who were misled by it only misunderstood it. The bottom line is that a definition that is misunderstood is a bad definition. And in the present case the old definition has led to misunderstandings, so revising it is well justified. ,------------------------------------------ | 2021-09-13 17:04:42 AntonErtl replies: | proposal - Reword the term "execution token" | see: https://forth-standard.org/proposals/reword-the-term-execution-token-#reply-771 `------------------------------------------ Accepted with vote #21 12Y:0:0 ,------------------------------------------ | 2021-09-13 17:06:10 AntonErtl replies: | proposal - Reference implementations are not normative | see: https://forth-standard.org/proposals/reference-implementations-are-not-normative#reply-772 `------------------------------------------ Accepted with vote #22 12Y:0:0 ,------------------------------------------ | 2021-09-13 17:12:42 AntonErtl replies: | proposal - Wording change for "COMPILE,": harmonization with terms | see: https://forth-standard.org/proposals/wording-change-for-compile-harmonization-with-terms#reply-773 `------------------------------------------ The committee accepted the following wording change (Vote #23, 12Y:0:0): Replace the "Execution" section of the glossary entry for COMPILE, word by the following: >Execution: > ( xt -- ) > > Append the semantics identified by xt to the execution semantics of the current definition. ,------------------------------------------ | 2021-09-13 17:27:31 AntonErtl replies: | testcase - Additional test for UTF-16 | see: https://forth-standard.org/standard/core/CComma#reply-774 `------------------------------------------ If your system passes your test, it is unclear what you disagree with. ,------------------------------------------ | 2021-09-14 11:38:47 ruv replies: | proposal - Reword the term "execution token" | see: https://forth-standard.org/proposals/reword-the-term-execution-token-#reply-775 `------------------------------------------ > Accepted with vote #21 12Y:0:0 It seems, the new definition introduces more problems than it allegedly solves. The proposed variant: > execution token: A value that can be passed to `EXECUTE` (6.1.1370) has the following problems. 1. This basic definition Inalienably refers to the Forth word `EXECUTE`. It either means that there is a lack of terms and the terminology should be better developed, or that just this definition is too poor. In any case, by this factor the new definition worse than the old one. 2. This definition is indirectly **recursive** via the data type symbol _xt_. Just ask what a value, according to 6.1.1370, can be passed to `EXECUTE`? — an execution token only! 3. This definition introduces a new lacuna into the normative text. The glossary entry [6.1.1370 EXECUTE](https://forth-standard.org/standard/core/EXECUTE) says that `EXECUTE` performs the semantics identified by _xt_, but now the standard nowhere says that an _xt_ value (a value of the corresponding data type "execution token") identifies semantics, and what semantics. A more detailed explanation of the item 2. A value that can be passed to `EXECUTE` is limited by the data type that has the symbol _xt_. This symbol is dedicated for the data type "execution token" (see [3.1 Data types](https://forth-standard.org/standard/usage#table:datatypes)). According to the the old definition, a value of this data type identifies execution semantics. But according to the new definition, a value of this data type is a value that can be passed to `EXECUTE`, i.e., the value, that has the data type symbol _xt_, i.e., that has the data type "execution token". Thus, by the new definition, "execution token" is a value that is an execution token. Perfect tautology! This "definition" just says nothing. A term definition that defines nothing is a confusing definition, so it's a bad definition. ----- It's a mistake that the new version of this proposal was not publicly discussed before voting (and a time was not provided for that). I can't find a fair explanation why all 12 TC members, without exclusions, voted for this version. Probably, due to some circumstances, the most TC members voted by a blind confidence, without enough immersing into the problem. I'm sorry.