Digest #192 2022-08-14

Contributions

[251] 2022-08-13 20:16:29 ruv wrote:

proposal - Clarification for execution token

Author

Ruv

Change Log

  • 2022-08-13 Initial version

Preceding history

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, NAME>INTERPRET and NAME>COMPILE. 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 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.

[252] 2022-08-13 23:24:52 ruv wrote:

proposal - Exclude zero from the data types that are identifiers

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 implies that an execution token cannot be zero.
  • FIND-NAME 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

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, 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

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 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 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 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 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 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 Data-type relationships:

fam ? x;

fileid ? x \ {0};