Digest #152 2021-05-16
2021-05-15: Initial version
A presupposition: in the text of the standard the same terms should be used for the same meaning, use of other terms instead of already defined terms should be avoided.
One expression in the specification for
COMPILE, is not in harmony with terms definitions.
The part "the definition represented by xt" is not enough defined. According to the terms definitions, an execution token identifies the execution semantics of a definition. So, the defined term (and it's wording) is preferred.
Use a wording that is based on the defined terms.
Insertion and deletions:
Append the execution semantics
of the definition representedby xt to the execution semantics of the current definition.
Rationale. No need to mention "the definition" since execution semantics are always connected with some definition (named or anonymous).
Replace the "Execution" section of the glossary entry for
COMPILE, word by the following:
( xt -- )
Append the execution semantics identified by xt to the execution semantics of the current definition.
A proposal to standardize two's complement representation of negative numbers has been approved by the committee in 2015, so the next standard will contain that. No Forth systems that use other representations of negative integers are known.
Just to close this question concerning a JIT compiler:
for example a JIT compiler that might want a set of actions where the intent is not to immediately interpret, compile or postpone but to provide input for a later compilation pass.
If the action for compilation (and reproduction) is defined in such a way that it provides input for a later compilation pass, then the automated action for
POSTPONE will generate the input for a later compilation pass too, automatically. Since the action for
POSTPONE is just expressed via other actions.
So this example of a JIT compiler doesn't show that
POSTPONE action cannot be automated.
To be more concrete, please provide a particular code example when
POSTPONE action cannot be automated, by your view.
One simple and almost portable implementation of
POSTPONE is following (now slightly shorter):
: POSTPONE ( "name" -- ) BL WORD FIND DUP 0= -13 AND THROW 1 = ( xt flag-compilation ) IF COMPILE, EXIT THEN LIT, ['] COMPILE, COMPILE, ; IMMEDIATE
This implementation uses the non-standard
LIT, word (that is factor of
LITERAL), and applies Tick to
COMPILE, (that is ambiguous in the general case due to undefined interpretation semantics for
COMPILE, at the moment). Also this implementation relies on the TC reply to RFI Q99-027 and doesn't meet the common expectations concerning a system behavior in this regard (a more completed implementation can be found in my gist on GitHub).
LIT, execution: ( x -- ) append the run-time semantics "place x on the stack" to the current definition.
LIT, is absent, it can be replaced by the phrase
0 <# #S #> EVALUATE in the definition above.
LITERAL can be defined via
LIT, and vise versa:
: LITERAL ( x -- ) LIT, ; IMMEDIATE : LIT, ( x -- ) POSTPONE LITERAL ;
To make applying Tick to
COMPILE, compliant, it's enough to redefined it:
: COMPILE, ( xt -- ) COMPILE, ;