6 Glossary

6.1.0070 ' tick CORE

( "<spaces>name" -- xt )

Skip leading space delimiters. Parse name delimited by a space. Find name and return xt, the execution token for name. An ambiguous condition exists if name is not found. When interpreting, ' xyz EXECUTE is equivalent to xyz.

See:

Rationale:

Typical use: ... ' name.

Many Forth systems use a state-smart tick. Many do not. Forth-2012 follows the usage of Forth 94.

Testing:

T{ : GT1 123 ;   ->     }T
T{ ' GT1 EXECUTE -> 123 }T

ContributeContributions

JohanKotlinskiavatar of JohanKotlinski [11] Request for clarification2015-12-25 23:32:43

"An ambiguous condition exists if name is not found. When interpreting, ' xyz EXECUTE is equivalent to xyz."

Which of these two statements have precedence? I.e., if xyz is not found, should ' xyz EXECUTE be equivalent to xyz or will it cause an ambiguous condition?

AntonErtlavatar of AntonErtl

My impression is that the "ambiguous condition" part is specification, whereas the "When interpreting" part is just an illustration of the previous specifications. Are you thinking about the case

' 123 execute

where there is no word "123". No, that is certainly not expected to be equivalent to text-interpreting 123.

Reply New Version

ruvavatar of ruv [96] Ambiguous condition in case of undefined execution semanticsComment2019-07-16 15:12:55

1. By the definition, an execution token identifies some execution semantics.

2. The specification of this word (i.e. Tick ') implies that when a word has execution semantics it shall have the interpretation semantics too, and performing its execution semantics in interpretation state shall be identical to performing its interpretation semantics.

3. But this specification does not imply the inverse — that if a word has the interpretation semantics it shall have execution semantics too. For example 123 has the interpretation semantics, but it may not have execution semantics. In such case Tick cannot return any meaningful xt for it.

NB: IIRC in some Forth systems Tick and FIND can return meaningful xt for the numbers (but in any case, such Forth system can be easily implemented).

4. Therefore, an ambiguous condition should exist if ' is applied to a word with undefined execution semantics (i.e. when the standard does not explicitly specify execution semantics). The examples of such words are: dual-semantics words like TO, S", the words with undefined interpretation semantics like IF, the numbers.

ruvavatar of ruv

In the fragment above: "it may not have execution semantics" — I don't sure that the grammatical form choice was suitable. I meant "execution semantics may be absent for it".

AntonErtlavatar of AntonErtl

Ticking words with undefined interpretation semantics is already ambiguous (4.1.2); same for TO, ACTION-OF and IS.

I think only S" and S" would be affected by the proposed change. These words are implemented as STATE-smart words by some systems, and I think that there is consensus that the standard should not exclude such implementations, so ticking and POSTPONEing should be ambiguous for them, too.

ruvavatar of ruv

I would like to stress the very different rationales in the cases of Ticking ambiguity and POSTPONEing ambiguity.

The Ticking ambiguity (in the certain cases) is the result of the normative specification text regardless of the particular Forth system implementations.

The POSTPONEing ambiguity (in the certain cases) is just a concession to some Forth system implementations (see the discussion wrt TO). Actually, it is not so difficult to implement POSPTONE even in some ad-hoc approach for those five special standard words, since the compilation semantics for these words are well defined (see the comment for POSTPONE).

PeterKnaggsavatar of PeterKnaggs

We have reviewed this at the standards meeting. This is being folded into a proposal coming to you in the near future.

ruvavatar of ruv

Please take into account that proposed change also affects (very rightful) the words that are created by SYNONYM (in the current revision), since execution semantics for them are not specified.

At the moment, the words that are created by SYNONYM, may be ticked. But the execution semantics of the newname may be unequal to the execution semantics of the oldname, and they are unequal in the most cases in the reference implementation of SYNONYM.

An example (according to the the reference implementation).

SYNONYM FOO 0=

For FOO and 0=:

  • The interpretation semantics are equal.
  • The compilation semantics are equal.
  • The execution semantics are not equal.

This inequality can be shown by the following code:

: [E] EXECUTE ; IMMEDIATE
0 ' 0=  ] [E] [ . \ prints -1
0 ' FOO ] [E] [ . \ prints 0 (or even throw exception)

NB: it is not a mistake of the reference implementation, since such behavior of SYNONYM is allowed by the specification.

Reply New Version

JimPetersonavatar of JimPeterson [176] Is Tick Immediate?Request for clarification2021-01-22 02:52:22

I'm confused. Is ' an immediate word or not?

If I do:

: test ' DUP ;
1 test SWAP

Do I get:

( xtD 1 )

where xtD is the execution token of DUP that got swapped with the 1, or do I get:

( 1 xtS xtS )

where xtS is the execution token of SWAP that got duplicated?

The existence of ['] certainly implies that ' is not immediate, and that if you want to have an immediate effect, you should use [']. Maybe that's what the documentation is trying to imply by not having separate "Compilation:" and "Runtime:" sections for this word? Many of the simpler words don't have such sections. Still, it may be better to explicitly state when the parsing and finding occurs... just for the sake of clarity. Maybe add another test to the "Testing:" section?

AntonErtlavatar of AntonErtl

You get ( 1 xtS xtS ).

' has default compilation semantics, i.e., is not immediate, as you noted from the absence of a "Compilation:" section.

Maybe we should add a caveat like you suggest to the Rationale for '. While a common argument is that the standard is not intended as an introduction to Standard Forth, this comment demonstrates that adding to the rationale could be useful; in particular, ' in fig-Forth works differently from ' in Standard Forth, so it's not just inexperienced users that might be confused.

AntonErtlavatar of AntonErtl

The question has been answered, closing.

Closed
Reply New Version

ruvavatar of ruv [346] Eliminating ambiguous conditions for TickRequest for clarification2024-06-20 15:25:45

I'm interested in how we want to define Tick's behavior in edge cases, as part of the general trend of reducing the number of ambiguous conditions.

Undefined word

When a word is not found (regardless of STATE), Tick shall throw an exception -13 ("undefined word"). It's obvious.

Undefined interpretation semantics

When interpretation semantics for the word are not defined by the standard, Tick shall do one from the following options:

  • return xt for a system-defined behavior (so, an ambiguous condition exists if this xt is executed);
  • throw exception -32 "invalid name argument";
  • throw exception -13 "undefined word" (I think, this option is undesired. Can we exclude it?).

This case is for the words like if, >r, exit, begin, etc.

Interpretation semantics are defined, but execution semantics undefined

The main question is this: should we allow Tick to throw an exception if interpretation semantics for the word are defined, but execution semantics are not defined?

At the moment, it's for the five standard words: s", s\", to, is, action-of.

Most systems in this case return xt that, when executed in interpretation state, performs the interpretation semantics for the word. Behavior in compilation state vary from system to system. So, by the fact, an ambiguous condition exists only when this xt is executed in compilation state.

What do you think?

Reply New Version