attempting to obtain the execution token

attempting to use the execution token

This change destandardizes implementations where a word like IF cannot be found in interpretation state and ' IF throws an exception in such case.

Two hours of wordsmithing with PK, HO, and ruv resulted in:

In the glossary entries 6.1.0070 ' (Tick) and 6.1.2510 ['] (BracketTick) replace the phrase:

An ambiguous condition exists if name is not found.

by

Throw -13 if name is not found.

and append:

If name has no execution semantics or no interpretation semantics, performing the semantics identified by the xt is ambiguous.

In the glossary entries 6.2.2295 TO, 6.2.1725 IS, 6.2.0698 ACTION-OF,

replace the phrase:

An ambiguous condition exists if any of POSTPONE, [COMPILE], ' or ['] are applied to TO.

by the phrase:

An ambiguous condition exists if POSTPONE or [COMPILE] are applied to TO.

In the section 4.1.2 Ambiguous conditions replace the phrase:

attempting to obtain the execution token, (e.g., with 6.1.0070 ', 6.1.1550 FIND, etc. of a definition with undefined interpretation semantics;

by the phrase

a word does not have both interpretation and execution semantics, ', FIND or SEARCH-WORDLIST return an xt for that word, and the semantics identified by that xt are performed.

We should examine all the words that have not both interpretation and execution semantics for possible unintended consequences.

One problem with the proposal (both the original and the wordsmithed version) is that the following is ambiguous:

synonym my+ +
1 2 ' my+ execute

The reason is that SYNONYM defines only interpretation and compilation semantics of MY+, not the execution semantics, so this ambiguous condition would strike.

My suggestion at fixing this is:

• Instead of covering both interpretation and execution semantics in the ambiguous condition, cover just interpretation semantics and S" S" TO IS ACTION-OF.

• ' ['] FIND SEARCH-WORDLIST return an xt identifying the interpretation semantics.

I think that this is the right way to go because there are no words with defined execution semantics and different defined interpretation semantics. Basically, they are the same, and the only reason why we have them as separate concepts in the standard is that we have some words (e.g., >R) where we define the compilation semantics through execution semantics, but where we undefine the interpretation semantics. An alternative would be to define such words with compilation semantics and run-time semantics (i.e., without execution semantics), and replace "interpretation semantics" with "execution semantics" in the rest of the document.

Problem [...] Previous proposals to modify ' have focused on ' itself. This proposal focuses on the use of the returned xt.

The problem is unclear from this description. Probably, the implied problem is the same as in my proposal about Tick, namely that applying Tick to some words (e.g. to s") is implicitly ambiguous since the corresponding execution semantics are not specified.

No current system is disenfranchised. It can continue doing what it already does.

It's incorrect.

Currently, a system may throw an exception when it encounters (in interpretation state) the fragment ' to, thanks to the declaration of an ambiguous condition when Tick is applied to to.

After proposed change a system is not allowed to throw an exception in this case (i.e., on ' to), since this declaration of an ambiguous condition is removed. So, this change is not back compatible.

Now a system will be forced to return an xt in this case, but the corresponding execution semantics are not specified anyway. For example, a system is allowed to return just 0.

Well, what is a profit of this change? Could anybody provide a use case, a standard program that applies Tick to to and does anything useful with the returned value, when the corresponding execution semantics are undefined?

In preparation for my version of this proposal I have tested the behaviour of existing systems. I wrote a test program that exercises the behaviour of various systems in contentious cases, and ran it on the following systems:

• Gforth 0.7.9_20220901
• iForth 5.0.27
• lxf 1.6-982-823
• SwiftForth 3.11.0
• VFX 64 5.11 RC2

The results are:

The entries in the table have the following meanings:

• behaviour1: like execution semantics, but apparently r@ accesses the wrong return stack item.

• behaviour2: my theory for the observed behaviour is that the execution semantics of exit is performed, but (like in behaviour1) applied to the wrong return stack item, resulting in a noop.

• behaviour3: looking at the output of SEE, it seems to be the interpretation semantics, but the actual behaviour does not quite fit.

• behaviour4: compile, performs (rather than appends) the interpretation semantics and leaves the xt on the stack.

• unclear: I have no explanation for the behaviour.

Concerning this proposal in general — see also my comment about reducing ambiguity on some degree.