Proposal: [251] Clarification for execution token

Informal

This page is dedicated to discussing this specific proposal

ContributeContributions

ruvavatar of ruv [251] Clarification for execution tokenProposal2022-08-13 20:16:29

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.

Reply New Version