Digest #166 2021-09-15
Contributions
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:
It inalienably refers to the
CREATEword ( Forth-2012 contains only one such definition in the section 2.1. Definitions of terms).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.
It connects a data field to a word defined via
CREATE. But a sophisticatedSYNONYMcan keep these association for the newname (and the new xt) too. So, there is no need to restrict this association byCREATEin the term definition.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:
TheA data space region associated witha word defined via CREATEa Forth definition.
or another variant:
data field:
TheA data space region associated with a worddefined 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).
Perhaps a better way is to formally associate a data field with an execution token, as it actually is (see >BODY).
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) by the following:
A data space region associated with a Forth definition.
Replies
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.
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).
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.
Accepted with vote #21 12Y:0:0
Accepted with vote #22 12Y:0:0
proposal - Wording change for "COMPILE,": harmonization with terms
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.
If your system passes your test, it is unclear what you disagree with.
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.
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.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!This definition introduces a new lacuna into the normative text. The glossary entry 6.1.1370 EXECUTE says that
EXECUTEperforms 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). 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.