Proposal: Incorrect use of semantics terms
This page is dedicated to discussing this specific proposal
ContributeContributions
ruv
[365] Incorrect use of semantics termsProposal2024-09-25 18:35:27
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)
ruvNew Version: Incorrect use of semantics terms
Author
Ruv
Change Log
- 2024-09-25 Initial revision
- 2024-09-26 Add sentences about an environmental restriction and environmental dependency.
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.
So, that is an inconsistency (or perhaps an omission or mistake) in the use of a formal term.
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.
So, that is an inconsistency (or perhaps an omission or mistake) in the use of a formal term.
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.
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 is 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.
- 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.
Add notes about an environmental restriction and environmental dependency concerning behavior of POSTPONE (see also "Consequences" below).
- 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.
In the "Compilation" section of the glossary entry 6.1.2033 POSTPONE add the paragraph:
A Forth system that provides
POSTPONEthat, when applied to an immediate word, appends the execution semantics of the word to the current definition, imposes an environmental restriction on programs: this definition (to whichPOSTPONEappends the semantics) shall be executed in compilation state only.
A program, which assumes thatPOSTPONE, when applied to an immediate word, appends the execution semantics of the word to the current definition, has an environmental dependency.
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:
On the other hand, it is easy to implement POSTPONE according to the specification:
[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)
achowe
Circular references in implementation examples are hugely confusing when used before the definition exists. In the above example the definitions of LIT, and leave-compilation reference POSTPONE before it is defined. A word like POSTPONE is conceptually very complex, compared to say SWAP, that many misunderstandings by novice developers arise from these circular references.
It has been commented before that circular references in implementation examples are acceptable and might make for quick clean short code, but IMO they simply compound the confusion to anyone who is not a Committee member nor seen the evolution of the language. This harms learning and adoption by new comers.
Would this be clearer?
: lit, (C: x -- ; S: -- x ) ['] LIT COMPILE, , ;
: leave-compilation ( -- ) 0 STATE @ ;
ruv
Circular references in implementation examples are hugely confusing when used before the definition exists.
Actually, it is a polyfill that intentionally redefines postpone.
Yes, to make it clearer, a system-dependent implementation can be provided.
For example, assuming that [ and literal are immediate words:
: compilation ( -- flag ) state @ 0<> ;
: enter-compilation ( -- ) ] ;
: leave-compilation ( -- ) ['] [ execute ;
: execute-compiling ( i*x xt -- j*x )
compilation if execute exit then
enter-compilation execute leave-compilation
;
[undefined] lit, [if]
: lit, ( x -- ) ['] literal execute-compiling ;
[then]
Is it simpler?
postpone is the same.
['] LIT COMPILE, , is more system specific and could be difficult to understand.