Proposal: Incorrect use of semantics terms

Author

Ruv

Change Log

• 2024-09-25 Initial revision

Problem

The section 2.1 Definitions of terms gives the following definitions:

• interpretation semantics:The behavior of a Forth definition when its name is encountered by the text interpreter in interpretation state.
• compilation semantics: The behavior of a Forth definition when its name is encountered by the text interpreter in compilation state.

These definitions are very good. Essentially, they talk about observable behavior, behavior that the Forth system exhibits under the specified conditions (namely, the word name is encountered in interpretation state or the word name is encountered in compilation state) and that a standard program or user can detect.

Note that if some effect cannot be detected under the specified conditions, than this effect is not a part of the corresponding semantics, and if some effect is a part of semantics, it can be detected under the corresponding conditions.

Almost in all cases when these terms are used in the normative parts, they are used correctly.

The problem is that in a few places these terms are used incorrectly. This produces inconsistency, confusing, many questions and disputes.

There are two places where they are used incorrectly:

• about default interpretation semantics,
• about compilation semantics of an immediate word.

About default interpretation semantics

The section 3.4.3.2 Interpretation semantics says:

• Unless otherwise specified in an "Interpretation:" section of the glossary entry, the interpretation semantics of a Forth definition are its execution semantics.

We can create a word whose execution semantics, when performed in compilation state, exhibit effects that cannot be detected when the name of this word is encountered by the Forth text interpreter in interpretation state. It means, these effects are not a part of the interpretation semantics for this word. Thus, the interpretation semantics for this word are not the execution semantics of this word.

An example:

: foo1 ( -- 1 | ) s" 1" evaluate ;

When the execution semantics of foo1 are performed in compilation state, something is appended to the current definition. This effect is not a part of the interpretation semantics of this word. Thus, the interpretation semantics of this word are not the execution semantics of this word .

This is an inconsistency (if not a conflict) in terminology.

Discussion

There is a point of view that the section 3.4.3.2 defines a different meaning for the term "interpretation semantics" for the case when "Interpretation" section is absent. But this is not true. Every term is defined separately and explicitly. In this section the term "interpretation semantics" is used rather than defined.

About compilation semantics for an immediate word

The section 2.1 Definitions of terms says:

• immediate word: A Forth word whose compilation semantics are to perform its execution semantics.

This definition does not say that the execution semantics shall be performed in compilation state. It means, they can be performed in interpretation state too. But we can create a word whose execution semantics, when performed in interpretation state, exhibit effects that cannot be detected when the name of this word is encountered by the Forth text interpreter in compilation state. It means, these effects are not a part of the compilation semantics of this word. Thus, the compilation semantics of this word are not to perform the execution semantics of this word (regardless the state).

An example:

: foo2 ( -- 2 | ) s" 2" evaluate ; immediate

When the execution semantics of foo2 are performed in interpretation state, the number 2 is placed on the data stack. This effect is not a part of the compilation semantics of this word. Thus, the compilation semantics of this word are not to perform the execution semantics of this word.

Again, this is an inconsistency (if not a conflict) in terminology.

Discussion

There is a point of view that the definition for the term "immediate word" also defines another meaning for the term "compilation semantics", that applies to immediate words only. But this not true. Because every term is defined separately and explicitly. In this definition the term "compilation semantics" is used rather than defined.

Solution

Change wording in the mentioned cases in such a way that the "interpretation semantics" and "compilation semantics" terms are used correctly:

• Unless otherwise specified in an "Interpretation:" section of the glossary entry, the interpretation semantics of a Forth definition are to perform its execution semantics in interpretation state.

• immediate word: A Forth word whose compilation semantics are to perform its execution semantics in compilation state.

Proposal

In the section 3.4.3.2 Interpretation semantics, replace the sentence:

Unless otherwise specified in an "Interpretation:" section of the glossary entry, the interpretation semantics of a Forth definition are its execution semantics.

with the sentence:

Unless otherwise specified in an "Interpretation:" section of the glossary entry, the interpretation semantics of a Forth definition are to perform its execution semantics in interpretation state.

In the section 2.1 Definitions of terms, replace the sentence:

immediate word: A Forth word whose compilation semantics are to perform its execution semantics.

with the sentence:

immediate word: A Forth word whose compilation semantics are to perform its execution semantics in compilation state.

Consequences

The inconsistency in the term "immediate word" was used to argue that the word POSTPONE, when applied to an immediate word, shall append the execution semantics of the word to the current definition, because they are allegedly always equivalent to the compilation semantics of the word.

This inconsistency cannot be used anymore.

If a Forth system provides the word POSTPONE, which when applied to an immediate word appends the execution semantics of the word to the current definition, this perhaps adds an environmental restriction to the Forth system.

On the other hands, it is easy to implement POSTPONE correctly:

[undefined] lit, [if]
  : lit, ( x -- ) postpone literal ;
[then]
: compilation  ( -- flag ) state @ 0<> ;
: enter-compilation  ( -- )           ] ;
: leave-compilation  ( -- )  postpone [ ;
: execute-compiling ( i*x xt -- j*x )
  compilation    if  execute  exit  then
  enter-compilation  execute  leave-compilation
;
: postpone ( "name" -- )
  parse-name find-name dup 0= -13 and throw name>compile ( x xt.compiler )
  compilation if swap lit, lit, ['] execute-compiling compile, exit then
  execute-compiling
; immediate

(see other variants in my post at ForthHub)