Proposal: Tick and undefined execution semantics

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.

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.

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.

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?

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.

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

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.

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.

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.

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