Proposal: Tick and undefined execution semantics

Informal

This page is dedicated to discussing this specific proposal

ContributeContributions

ruvavatar of ruv Tick and undefined execution semanticsProposal2020-10-29 00:28:43

Author

Ruv

Change Log

Problem

Using of the word ' (Tick) is implicitly (and intrinsically) ambiguous in some cases, but this is not declared explicitly.

The word ' returns execution token that identifies execution semantics for the word in argument. Therefore, if execution semantics for a word are not defined by the standard, a program should not rely that Tick returns anything for this word, and that it returns control at all.

Solution

Declare an ambiguous condition for the case when Tick is applied to a word with undefined execution semantics.

For the most words, for which execution semantics are not defined, interpretation semantics are also not defined. And the standard already has the general rule that applying Tick to a word with undefined interpretation semantics is ambiguous. For the remaining words, for which interpretation semantics are defined, but execution semantics are not defined, the standard declares ambiguous condition individually for each such word. The only word that falls out of this line is the FILE S" word.

The right way is to remove individual workarounds and introduce the single general rule.

Actually, it would be enough to declare an ambiguous condition only in the case of undefined execution semantics, and remove the declaration of an ambiguous condition in the case of undefined interpretation semantics. But we cannot do it while the compilation semantics for some words with undefined interpretation semantics still defined via execution semantics (e.g. >R ).


Side note

The situation with these words can be made better in some of the following ways:

a. Rename Execution section into Run-time section, and add Compilation section into each of these words.
b. Rename Execution section into Run-time section, and change the default compilation semantics that they are to append run-time semantics, and default run-time semantics are to perform execution semantics.
c. Rename Execution section into Run-time section, and change the default compilation semantics that they are to append run-time semantics if they are defined, or to append execution semantics otherwise.


So, at the moment, the general rule is that it's ambiguous to apply Tick to a word with undefined execution semantics or undefined interpretation semantics.

After refactoring the specifications for the words mentioned above, the part concerning undefined interpretation semantics can be removed.

All above is applied to ['] BracketTick as well as for Tick.

Proposal

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

Remove the phrase:

An ambiguous condition exists if name is not found.

And add the following Note

Note
An ambiguous condition exists if name is not found, or execution semantics for name are undefined, or interpretation semantics for name are undefined.

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.

The rationale: since in the standard, the general ambiguous conditions are not repeated for each word in argument.

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 obtain the execution token (e.g., with 6.1.0070 ', 6.1.1550 FIND, etc.) of a definition with undefined execution semantics or undefined interpretation semantics;

(the excessive comma and missing right parenthesis are also fixed).

AntonErtlavatar of AntonErtl

This is at the same time both excessive and fails to make existing state-smart implementations of S" and S" standard-compliant.. E.g., SwiftForth fails

: postpone-s"
    postpone s" ;
: PSQ4 [ postpone-S" XY" ] ;
psq4 type
psq4 type \ should type "XY", SwiftForth stack-underflows

No ' in sight, so your proposal will not make SwiftForth's S" compliant.

As mentioned elsewhere, a more measured and more precisely targeted approach is to add the same ambiguous condition to S" and S" that allows STATE-smart TO, IS, and ACTION-OF.

ruvavatar of ruv

This [...] fails to make existing state-smart implementations of S" and S\" standard-compliant.

This proposal is not intended to make these implementations standard-compliant. Its intention is to explicitly make non-standard a code like ' S" or ['] S", due to its unclear semantics.

Before that somebody could suppose that such code may take place in a standard program. After that such code is explicitly non-standard. I should have expressed this more clear.

So your example with POSTPONE is not relevant.

If somebody wants to make code POSTPONE S" non-standard, a separate proposal can be made. But I dislike this idea, since semantics of this code is unambiguous and clear.

By my understanding, to make code ' S" standard-compliant, the standard should define execution semantics for S". But the codePOSTPONE S" is both standard-compliant and clear without any changes. The single-xt systems, that handle this code in an unexpected way, can be fixed without changing their single-xt property.

Reply New Version