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


,------------------------------------------
| 2020-02-20 09:55:14  ruv  wrote:
| proposal - NAME>INTERPRET wording
| see: https://forth-standard.org/proposals/name-interpret-wording#contribution-129
`------------------------------------------
### Connection of xt with interpretation semantics
The spec says that "_xt_ represents the interpretation semantics of the word _nt_". But by 2.1 Definitions of terms, execution token (xt) identifies not interpretation semantics but execution semantics.

#### Solution
Use a wording that is slightly better harmonized with the terms definitions.
> The execution token _xt_ identifies the execution semantics that performs the interpretation semantics for the word identified by the name token _nt_.


### Meaning of 0

It seems that the spec implies that if `NAME>INTERPRET` returns 0 then interpretation semantics is __undefined__ for the corresponding word (by the premise: a specification should describe all possible variants; and the variant is only one in this case).

But actually, in some cases a Forth system just cannot provide an xt that performs the __defined__ interpretation semantics for the corresponding word. Particularly, we can have this case when a "dual semantics" word is implemented as a STATE-dependent immediate word. Technically it is possible to return an xt (e.g. via generation of the corresponding definition on the fly), but a Forth system authors may choose to not implement such functionality.

NB: it is incorrect to return an _xt_ that identifies STATE-depended execution semantics, when the interpretation semantics for the corresponding word don't specified as STATE-depended.  Perhaps the `NAME> ( nt -- xt|0 )` word from [Forth-83](https://www.complang.tuwien.ac.at/forth/fth83std/FORTH83.TXT) experimental proposals can be standardized to cover such cases. This word should return _xt_ that identifies the execution semantics for the word identified by _nt_.
#### Solution

Explicitly mention the second meaning of 0.

>  If `NAME>INTERPRET` returns 0 then either interpretation semantics is undefined for the word identified by _nt_, or the system cannot provide an _xt_ that preforms the defined interpretation semantics for this word.



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


,------------------------------------------
| 2020-02-07 07:26:29  ruv  replies:
| referenceImplementation - sample implementation that can also be interpreted
| see: https://forth-standard.org/standard/core/WITHIN#reply-353
`------------------------------------------
The original reference implementation does not have the mentioned issue, — it may work when interpreting.

You mean the ambiguous condition "interpreting a word with undefined interpretation semantics", but during interpretation of `WITHIN` word, the `>R` and `R>` words are __not interpreted__, since they __names__ are **not encountered** by the text interpreter. Therefore, this ambiguous condition isn't met.

Moreover, during interpretation of `WITHIN`, it does not matter whether interpretation semantics of any other word is defined by the standard or not.

See also the [terms definitions](/standard/notation) for "interpretation semantics" and "compilation semantics".



,------------------------------------------
| 2020-02-07 15:05:02  ruv  replies:
| requestClarification - Why RECURSE is needed?
| see: https://forth-standard.org/standard/core/RECURSE#reply-354
`------------------------------------------
It is important to add that creating and "smudging" a dictionary entry by Colon ":" is only one of several possible ways of implementing the requirements. All these details, such as a dictionary entry and smudging, are under the hood and not available for a standard program.
 


,------------------------------------------
| 2020-02-20 11:22:59  ruv  replies:
| proposal - NAME>INTERPRET wording
| see: https://forth-standard.org/proposals/name-interpret-wording#reply-355
`------------------------------------------
Without updating the meaning of returned 0 for `NAME>INTERPRET`, the only option for a Forth system that cannot, in some case, provide _xt_ that performs the corresponding interpretation semantics, is to don't provide `NAME>INTERPRET` word at all.