,---------------.
| Contributions |
`---------------´


,------------------------------------------
| 2021-05-15 17:53:09  ruv  wrote:
| proposal - Wording change for "COMPILE,": harmonization with terms
| see: https://forth-standard.org/proposals/wording-change-for-compile-harmonization-with-terms#contribution-200
`------------------------------------------
## 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,`](https://forth-standard.org/standard/core/COMPILEComma) is not in harmony with terms definitions.

The part "the definition represented by _xt_" is not enough defined. According to the [terms definitions](https://forth-standard.org/standard/notation#notation:terms), 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 <del>of the definition represented</del> <ins>identified</ins> 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:** <br/>
( _xt_ -- ) <br/>
Append the execution semantics identified by _xt_ to the execution semantics of the current definition. 



,---------.
| Replies |
`---------´


,------------------------------------------
| 2021-05-15 10:21:56  AntonErtl  replies:
| testcase - Inaccurate Test Cases?
| see: https://forth-standard.org/standard/double/DtoS#reply-692
`------------------------------------------
A [proposal to standardize two's complement representation of negative numbers](http://www.forth200x.org/twos-complement.html) 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.


,------------------------------------------
| 2021-05-15 18:22:00  ruv  replies:
| proposal - Recognizer RfD rephrase 2020
| see: https://forth-standard.org/proposals/recognizer-rfd-rephrase-2020#reply-693
`------------------------------------------
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.



,------------------------------------------
| 2021-05-15 21:09:40  ruv  replies:
| referenceImplementation - Portable implementation for POSTPONE
| see: https://forth-standard.org/standard/core/POSTPONE#reply-694
`------------------------------------------
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](https://groups.google.com/forum/message/raw?msg=comp.lang.forth/RmsDuen7YkY/xDvW74uzi30J/) and doesn't meet the common expectations concerning a system behavior in this regard (a more completed implementation can be found in my [_gist_](https://gist.github.com/ruv/fe2256dde1ca304f31ed925c8b998259) 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, ;
```