Proposal: Tick and undefined execution semantics - 2

Informal

This page is dedicated to discussing this specific proposal

ContributeContributions

StephenPelcavatar of StephenPelc Tick and undefined execution semantics - 2Proposal2021-09-08 10:15:49

Tick and undefined execution semantics

Proposal
8 September 2021
Stephen Pelc

Change Log

2021-09-08 Initial version

Problem

The value (xt) returned by ' (tick) may not be useful for words with no defined execution semantics. Since the development of the ANS-94 standard, two common system behaviors have emerged. Systems based on classical Forth provide some execution semantics for all words and may provide additional functionality, e.g. LOCATE or XREF. A more recent approach is for ' and friends to have an ambiguous condition (or error) for all words without execution semantics.

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

Solution

An implementation dependent result is returned by ' for words with undefined execution semantics.

No current system is disenfranchised. It can continue doing what it already does. It can continue to error, to declare an ambiguous condition or to carry on.

However, an ambigous condition may occur when a value returned by ' for a word with no execution semantics is used.

Proposal

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

If name has no execution semantics, the behavior of xt is implementation dependent and may lead to an ambiguous condition.

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:

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

ruvavatar of ruv

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.

AntonErtlavatar of AntonErtl

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.

AntonErtlavatar of AntonErtl

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.

ruvavatar of ruv

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?

Reply New Version