Proposal: NAME>INTERPRET wording

Author

Ruv

Change Log

2020-02-20 Initial comment for NAME>INTERPRET 2023-09-14 Make this proposal more formal

Problem

Currently the specification for name>interpret says that returned "xt represents the interpretation semantics of the word nt".

But actually, in some cases a Forth system cannot provide an xt that performs the defined interpretation semantics for the corresponding word regardless of the STATE.

Particularly, when the words like s" or to are implemented as STATE-dependent immediate words. Technically it is possible to return a correct xt according to the current specification (e.g. via generation of the corresponding definition on the fly), but it can be too burden.

Another minor problem is that it's not clear what the word represent means. According to the language of the standard, xt identifies some semantics.

Solution

The specification for name>interpret can be adjusted to solve the mentioned problem. There are two options:

1. Allow to return 0 if the system cannot return xt that identifies the interpretation semantics for the word identified by nt

2. Allow to return state-dependent xt, which performs interpretation semantics in interpretation state only.

Proposal

Replace the following phrase in the section 15.6.2.1909.20 NAME>INTERPRET:

xt represents the interpretation semantics of the word nt. If nt has no interpretation semantics, NAME>INTERPRET returns 0.

by the following phrase:

xt identifies the execution semantics for the word identified by nt. When this xt is executed in interpretation state, the interpretation semantics for the word is performed. If the system does not provide execution semantics for the word, NAME>INTERPRET returns 0.

• 2020-02-20 Initial comment for NAME>INTERPRET
• 2023-09-14 Make this proposal more formal
• 2023-09-19 Add rationale, better wording, fix some typos

Currently the specification for name>interpret says that returned "xt represents the interpretation semantics of the word nt".

But actually, in some cases a Forth system cannot provide an xt that performs the defined interpretation semantics for the corresponding word regardless of STATE.

Particularly, when a word like s" or to is implemented as STATE-dependent immediate word. Technically it is possible to return a correct xt according to the current specification (e.g. via generation of the corresponding definition on the fly), but it can be too burden.

Another minor problem is that it's not clear what the term represent means. According to the language of the standard, xt identifies some semantics.

Rationale

It should be clear from the specification how, having an nt, to perform the very behavior that a Forth system performs when the Forth text interpreter encounters, in interpretation state, the name of a word identified by this nt.

Namely, to perform this behavior, must the xt returned from name>interpret be executed only interpretation state, or it may be also executed in compilation state.

1. Allow to return 0 if the system cannot return xt that identifies the interpretation semantics for the word identified by nt (see also the clarification re execution tokens).
   • Probably, in this case we have to introduce a word like name> (experimental in Forth-83), which returns xt that identifies the execution semantics of the word identified by nt. Since otherwise a user-defined Forth text interpreter is impossible without correct find.

2. Allow to return state-dependent xt, which performs the interpretation semantics for the word in interpretation state only.

In this proposal I stick with the second option.

If anyone prefers the first option of has other objections, please feel free to share your ideas in a comment.

xt identifies the execution semantics of the word identified by nt. When this xt is executed in interpretation state, the interpretation semantics for the word are performed. If a Forth system does not provide such execution token for the word, NAME>INTERPRET returns 0.

• 2023-09-21 Add rationale re system-defined semantics, and declare an ambiguous condition

Particularly, when a word like s" or to is implemented as a STATE-dependent immediate word. Technically, it is possible to return a correct xt according to the current specification (e.g. via generation of the corresponding definition on the fly), but it can be too burden.

How to perform interpretation semantics

System-defined semantics

If the standard does not define interpretation semantics for a word, a Forth system may provide system-defined interpretation semantics for the word (see A.3.4.3.2).

The same is true for execution semantics — if the standard does not define them for a word, a Forth system may provide system-defined execution semantics for the word. But, due to 6.1.0070, performing these execution semantics in interpretation state must be always equivalent to performing interpretation semantics for the word (regardless whether they are standard-defined or system-defined).

In this proposal I stick to the second option.

If anyone prefers the first option or has other objections, please feel free to share your ideas in a comment.

Replace the following paragraph in the section 15.6.2.1909.20 NAME>INTERPRET:

by the following paragraphs:

An ambiguous condition exists in any of the following conditions:

• interpretation semantics for the word are not defined by this standard and xt is executed;
• execution semantics of the word are not defined by this standard and xt is executed in compilation state;

• 2023-09-22 Require xt if interpretation semantics for the word are defined by the standard

Connection with Tick

It we want ticking any word for which interpretation semantics are defined by the standard, name>interpret cannot return 0 for these words.

Forth systems in which name>interpret returns 0 for such a word are unknown to the author.

xt identifies the execution semantics of the word identified by nt. When this xt is executed in interpretation state, the interpretation semantics for the word are performed.

If and only if interpretation semantics for the word are not defined by this standard and the Forth system does not provide the execution token for the word, NAME>INTERPRET returns 0.

• 2023-09-28 Add a clause re STATE-dependent execution semantics in Problem, add a section re execution of xt meaning in Rationale, better wording and formatting in some places

1. It's currently unclear from the specification for name>interpret how to perform the interpretation semantics for the word identified by nt — namely, how to perform the behavior that a Forth system performs when the Forth text interpreter, while in interpretation state, encounters the name of a word identified by this nt (see also Rationale below).

2. The specification for name>interpret says that returned "xt represents the interpretation semantics of the word nt". But actually, in some cases a Forth system cannot provide an xt that performs the interpretation semantics for the corresponding word regardless of STATE.

Particularly, when nt is for a word whose execution semantics depends on STATE, or for a word like s" or to, if it is implemented as an immediate word. Technically, it is possible to return a correct xt according to the current specification (e.g. via generation of the corresponding definition on the fly), but it can be too burden.

3. A minor problem is that it's not clear what the term represent means. According to the language of the standard, xt identifies some semantics.

It should be clear from the specification how, having an nt, to perform the very behavior that a Forth system performs when the Forth text interpreter, while in interpretation state, encounters the name of a word identified by this nt.

Namely, in the general case, to perform this behavior, must the xt returned from name>interpret be executed only in interpretation state, or it may be also executed in compilation state.

Execution of xt

In this proposal, the author assumes that compile, is equivalent to lit, ['] execute compile,, and therefore "xt is executed" means "the execution semantics identified by xt are performed" — no matter how — via execute directly, or as a part of execution semantics of another definition, in any nesting, when this part is appended by applying compile, to this xt.

NB: one consequence from this equivalence is that the words that operate on the return stack cannot be defined as ordinary words (see a corresponding discussion).

The same is true for execution semantics — if the standard does not define them for a word, a Forth system may provide system-defined execution semantics for the word. But, due to 6.1.0070, performing these execution semantics in interpretation state must always be equivalent to performing the interpretation semantics for the word (regardless whether they are standard-defined or system-defined).