Proposal: Better wording for "data field" term

Accepted

This page is dedicated to discussing this specific proposal

ContributeContributions

ruvavatar of ruv [214] Better wording for "data field" termProposal2021-09-14 08:55:49

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 word ( Forth-2012 contains only one such definition in the section 2.1. Definitions of terms).

  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).

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.

AntonErtlavatar of AntonErtl

At the 2022i meeting, we discussed the issue:

Mentioning CREATE is correct for the current state of the standard document, and helps the reader understand the limitations of the term "data field"; if the standard is changed such that other types of words can have data fields, we can change the the definition of this term at this time.

Concerning "The data space": This is qualified by the following text, so the meaning is clear to us at the meeting. However, if a clarification is wanted, it could be replaced with "The portion of data space" or "The part of data space".

ruvavatar of ruv

Concerning "The data space": This is qualified by the following text, so the meaning is clear to us at the meeting.

By what following text? The definition says only the following:

data field: The data space associated with a word defined via CREATE.

If you mean some following section, a term definition should not rely on them, I think. The term definitions and notations constitute a bedrock on which other parts are grounded. It's like axioms on which theorems are grounded.

However, if a clarification is wanted, it could be replaced with "The portion of data space" or "The part of data space".

The phrases "portion of data space", "part of data space", "data space region" are synonyms. A difference is that the later one is already used in other parts of the standard, but the two former are not. For example, see 3.3.3.2 Contiguous regions ("a region of data space..."), A.3.3.3.2 Contiguous regions ("The data space of a Forth system comes in discontiguous regions").

Probably, somebody can mean "a region of the data space" by "a data space", but it's better to avoid such looseness in a normative text.

ruvavatar of ruvNew Version: Better wording for "data field" term

Hide differences

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 word ( Forth-2012 contains only one such definition in the section 2.1. Definitions of terms).

  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.

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).

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.

A data space region associated with a Forth word defined by CREATE (6.1.1000)

ruvavatar of ruv

In the version of 2022-09-16 we retain referencing of CREATE. But it adds some complexity for SYNONYM (proposal), since a synonym for CREATE is another word.

UlrichHoffmannavatar of UlrichHoffmann

The committee considers this proposal formal and asks the author to change its status to "CfV - Call for Votes" whenever he deems it ready.

Formal

AntonErtlavatar of AntonErtl

This is a wording change, not a substantive change, so I don't think a CfV makes much sense. The committee voted (#32) in a vote starting at 2022-09-17, and the result is 8Y:1N:1A. This is usually considered to be enough for a consensus. Unfortunately, we did not discuss this vote at the 2023 meeting, so should we move it to Accepted, or should we discuss it at the next meeting? If the latter, please put it on the Agenda.

UlrichHoffmannavatar of UlrichHoffmannNew Version: Better wording for "data field" term

Hide differences

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 word ( Forth-2012 contains only one such definition in the section 2.1. Definitions of terms).

  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).

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 word defined by CREATE (6.1.1000)

Accepted
Reply New Version