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


,------------------------------------------
| 2019-09-13 09:53:48  ruv  wrote:
| comment - Reference implementation and POSTPONE
| see: https://forth-standard.org/standard/tools/SYNONYM#contribution-116
`------------------------------------------
`POSTPONE` (and `[COMPILE]`) should be tweaked to properly work for the words that are created by `SYNONYM` in the reference implementation. Actually, they should use `EXECUTE-COMPILING` (see an [example in a comment for POSTPONE](https://forth-standard.org/standard/core/POSTPONE#contribution-98)).

Perhaps the corresponding note should be appended into "Implementation" section.



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


,------------------------------------------
| 2019-09-13 07:46:12  ruv  replies:
| comment - Ambiguous condition in case of undefined execution semantics
| see: https://forth-standard.org/standard/core/Tick#reply-332
`------------------------------------------
Please take into account that proposed change also affects (very rightful) the words that are created by `SYNONYM` (in the current revision), since execution semantics for them are not specified.

At the moment, the words that are created by SYNONYM, may be ticked. But the execution semantics of the _newname_ may be unequal to the execution semantics of the _oldname_, and they are unequal in the most cases in the reference implementation of `SYNONYM`.

An example (according to the the [reference implementation](https://forth-standard.org/standard/tools/SYNONYM)).
```
SYNONYM FOO 0=
```
For `FOO` and `0=`:
- The interpretation semantics are equal.  
- The compilation semantics are equal.
- The execution semantics are __not equal__.

This inequality can be shown by the following code:
```
: [E] EXECUTE ; IMMEDIATE
0 ' 0=  ] [E] [ . \ prints -1
0 ' FOO ] [E] [ . \ prints 0 (or even throw exception)
```
NB: it is not a mistake of the reference implementation, since such behavior of `SYNONYM` is allowed by the specification.