[200] 2021-05-15 17:53:09 ruv wrote:

proposal - Wording change for "COMPILE,": harmonization with terms

Author

Ruv

Change Log:

2021-05-15: Initial version

Problem

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.

Solution

Use a wording that is based on the defined terms.

Insertion and deletions:

Append the execution semantics of the definition represented identified by 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).

Proposal

Replace the "Execution" section of the glossary entry for COMPILE, word by the following:

Execution:

( xt -- )

Append the execution semantics identified by xt to the execution semantics of the current definition.

[r692] 2021-05-15 10:21:56 AntonErtl replies:

testcase - Inaccurate Test Cases?

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.

[r693] 2021-05-15 18:22:00 ruv replies:

proposal - Recognizer RfD rephrase 2020

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.

[r694] 2021-05-15 21:09:40 ruv replies:

referenceImplementation - Portable implementation for POSTPONE

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.

If 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, ;