Proposal: [163] Tick and undefined execution semantics

Formal

This page is dedicated to discussing this specific proposal

ContributeContributions

ruvavatar of ruv [163] 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.

StephenPelcavatar of StephenPelc

In classical Forths and in VFX you can tick any word that has a name - provided that you have the search order correct. This is valuable for tools such as <b><f>LOCATE and <b><f>XREF. It is not an error to tick a word. There may be an error if the returned result is used incorrectly. In a dangerous language such as Forth, this is the programmer's problem.

With this usage, there are no ambiguous conditions when ticking a word. There may be ambiguous conditions when using the returned result. There are no ambiguous conditions in having a unique result.

I think that we just have to live with this - after all it's Forth.

ruvavatar of ruv

There are no ambiguous conditions when ticking a word.

It's wrong. By the Forth-2012, ticking of TO is ambiguous, as well many other words.

And the general rule is that an ambiguous condition exists when ticking a word that doesn't have default interpretation semantics. The only exception from this rule is S" word. I suggest to eliminate this strange exception and introduce a general rule (I will prepare the next version of the proposal with better wording).

The result of ticking S" (as well as the result or ticking TO) cannot be used in compilation state correctly in any standard system. If it's enough to make ticking TO ambiguous, why it isn't enough to make ticking S" ambiguous?

ruvavatar of ruv

It is not an error to tick a word. There may be an error if the returned result is used incorrectly.

I understand this point. But an ambiguous condition is a formal thing.

And concerning Tick there are two options:

  • declare an ambiguous condition for execution of the result of ticking in the certain cases;
  • declare an ambiguous condition for ticking in the certain cases.

The choice of the standard is the second option. And I agree, this choice is better than another, since it's simpler, less dangerous, more options for implementations.

StephenPelcavatar of StephenPelc

"It is not an error to tick a word. There may be an error if the returned result is used incorrectly." "I understand this point. But an ambiguous condition is a formal thing."

The ambiguous condition is generated by using the result, not by ticking the word.

I systems wish to perform checks in ' and friends, that is their privilege. However, the standard should never force a system to do so.

ruvavatar of ruv

The ambiguous condition is generated by using the result, not by ticking the word.

Forth-2012 declares that an ambiguous condition exists if a program ticks a word for which interpretation semantics are undefined.

Due to this declaration a Forth system is allowed to throw an exception when it encounters (in interpretation state) the phrase ' if, i.e, when a program even ticks if.

Also, due to this declaration the phrase ' if is prohibited for a standard program. And it only means that if a program contains this fragment, then this program is not a standard program.

If systems wish to perform checks in ' and friends, that is their privilege. However, the standard should never force a system to do so.

And it doesn't force!

E.g., the standard doesn't enforce a system what to do if ' is applied to if. It only enforces a standard program in this regard!


It seems you want to allow a standard program to tick any available word. But then you have to dictate systems what to do when Tick is applied to if (i.e. ' if or ['] if) and it will break back compatibility.

Perhaps you want to allow a standard program to tick to (but not if). But it doesn't make any sense, since a standard program cannot use the returned xt, since the corresponding semantics are not specified.

ruvavatar of ruv

A new idea to discuss

Initially I suggested to declare ambiguity when Tick is applied to any word for which are not defined both execution semantics and interpretation semantics.

But instead we can precisely specify this cases to reduce ambiguity on some degree.

We can say that if execution semantics for the word are not specified by the standard, the returned xt identifies some system-dependent execution semantics, and when this xt is performed in interpretation state, the interpretation semantics for the word are performed. Performing this xt in compilation state is ambiguous.

ruvavatar of ruv

This idea is close to the proposal [212] Tick and undefined execution semantics - 2

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

The difference is that I suggest to specify the behavior in interpretation state.

If the standard does not specify interpretation semantics for the word, then system-defined interpretation semantics are performed.

AntonErtlavatar of AntonErtl

This proposal satisfies the formality criteria and is therefore promoted to formal. Please promote it to CfV when you think that you are not going to change it anymore (proposals in CfV state must not be revised).

Formal
Reply New Version