Proposal: NAME>INTERPRET wording

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 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.