Proposal: Clarify FIND, more classic approach

Informal

This proposal has been moved into this section. Its former address was: /standard/core/FIND

This page is dedicated to discussing this specific proposal

ContributeContributions

ruvavatar of ruv Clarify FIND, more classic approachProposal2019-10-08 11:01:25

It is an alternative proposal to the one from Anton.

Problem

  1. The existing specification of FIND is unclear how the returned xt is connected with interpretation and compilation semantics for the corresponding word.

  2. In some popular Forth systems n=1 does not mean that the word is immediate.

Solution

Use the new wording in the specification for FIND.

Keep the original immediacy notion, but use another (more loose) wording for meaning of n in compilation state. The new wording allows to implement the words with undefined execution semantics as "dual-xt" words, and still allows (as it was before) to implement them as immediate STATE-dependent words. Also it allows to have the special definitions to compile the words with undefined interpretation semantics and defined execution semantics (like EXIT), and return proper values for them from FIND.

No need to mention that FIND may return c-addr 0 for the words with undefined interpretation semantics. It is a consequence of the clause that the returned values depend on STATE, and it is mentioned in the Rationale.

Don't change 4.1.2. Perhaps make FIND tighter later when it will be optional. The original specification guarantees that a user-defined text interpreter can interpret all ordinary and user-defined words at least.

Now many Forth systems don't use FIND by themselves but provide it for the old-fashion programs only. There is no much sense to restrict the implementation options of the modern Forth systems for the sake of the outdated approach. I think the modern Forth systems will tend to use Recognizer/Resolver approach for the special syntaxes and special words.

Proposal

Replace the text in the specification of FIND with the following.

( c-addr -- c-addr 0 | xt n )

Find the definition name whose name matches the counted string at c-addr. If the definition is not found, return c-addr and zero. Otherwise the definition is found, xt is the execution token for name, and n is 1 or -1. The all returned values may differ between interpretation and compilation state.

When the definition is found in interpretation state: if the definition is immediate then n is 1, otherwise n is -1; performing xt in intepretation state performs the interpretation semantics for name.

When the definition is found in compilation state: if n is -1, appending the semantics identified by xt to the current definition performs the compilation semantics for name, otherwise performing xt in compilation state performs the compilation semantics for name.

"Performing xt" means performing the execution semantics identified by the execution token xt.


Please check the gist at github for updating and corrections in this proposal.

ruvavatar of ruv

Have a look at the next version of FIND specification I have designed. It seems this variant is more accurate and quite better.

ruvavatar of ruvNew Version

Hide differences

It is an alternative proposal to the one from Anton.

It is an alternative proposal to the one from Anton.

Problem

  1. The existing specification of FIND is unclear how the returned xt is connected with interpretation and compilation semantics for the corresponding word.

  2. In some popular Forth systems n=1 does not mean that the word is immediate.

Solution

Use the new wording in the specification for FIND.

Keep the original immediacy notion, but use another (more loose) wording for meaning of n in compilation state. The new wording allows to implement the words with undefined execution semantics as "dual-xt" words, and still allows (as it was before) to implement them as immediate STATE-dependent words. Also it allows to have the special definitions to compile the words with undefined interpretation semantics and defined execution semantics (like EXIT), and return proper values for them from FIND.

Keep the original immediacy notion, but use another (more loose) wording for meaning of n in compilation state. The new wording allows to implement the words with undefined execution semantics as "dual-xt" words, and still allows (as it was before) to implement them as immediate STATE-dependent words. Also it allows to have the special definitions to compile the words with undefined interpretation semantics and defined execution semantics (like EXIT), and return proper values for them from FIND.

No need to mention that FIND may return c-addr 0 for the words with undefined interpretation semantics. It is a consequence of the clause that the returned values depend on STATE, and it is mentioned in the Rationale.

Some differences to the Anton's proposal

Don't change 4.1.2. Perhaps make FIND tighter later when it will be optional. The original specification guarantees that a user-defined text interpreter can interpret all ordinary and user-defined words at least.

More accurate wordings that are closer to the language of standard.

Now many Forth systems don't use FIND by themselves but provide it for the old-fashion programs only. There is no much sense to restrict the implementation options of the modern Forth systems for the sake of the outdated approach. I think the modern Forth systems will tend to use Recognizer/Resolver approach for the special syntaxes and special words.

Use "default interpretation semantics" criteria instead of referring to POSTPONE (item 3 in my comment).

Allow to implement words without interpretation semantics (e.g., IF) as immediate STATE-dependent words (as it was before).

Do specify what n means in all possible cases (news:qnko0l$jk2$1@dont-email.me).

Don't change 4.1.2. since FIND cannot and doesn't return xt for a definition with not default interpretation semantics. The new specification guarantees that a user-defined text interpreter can interpret any word that is found by FIND. Also, 4.1.2 should be updated independently by itself.

Nowadays many Forth systems don't use FIND by themselves but provide it for the old-fashion programs only. There is no much sense to restrict the implementation options of the modern Forth systems for the sake of the outdated approach. I think the modern Forth systems will tend to use Recognizer/Resolver approach for the special syntaxes and special words.

Proposal

Replace the text in the specification of FIND with the following.


FIND

( c-addr -- c-addr 0 | xt n )

Find the definition name whose name matches the counted string at c-addr. If the definition is not found, return c-addr and zero. Otherwise the definition is found, xt is the execution token for name, and n is 1 or -1. The all returned values may differ between interpretation and compilation state.

Find the definition name whose name matches the counted string at c-addr. If the definition is not found, return c-addr and zero. Otherwise the definition is found, return xt and n.

When the definition is found in interpretation state: if the definition is immediate then n is 1, otherwise n is -1; performing xt in intepretation state performs the interpretation semantics for name.

If name has default interpretation semantics, xt is the execution token for name, and n is 1 if name is immediate word, -1 otherwise. The returned values are the same regardless whether the definition is found in interpretation state or in compilation state.

When the definition is found in compilation state: if n is -1, appending the semantics identified by xt to the current definition performs the compilation semantics for name, otherwise performing xt in compilation state performs the compilation semantics for name.

If name has other than default interpretation semantics, xt is the execution token for an unspecified implementation-dependent definition, and n is 1 or -1, and the following conditions are met.

  1. When the definition is found in compilation state: if n is 1, performing xt in compilation state performs the compilation semantics for name, otherwise n is -1, and appending the execution semantics identified by xt to the current definition performs the compilation semantics for name.

  2. When the definition is found in interpretation state: if n is 1, xt and n are the same when the definition is found in compilation state, otherwise n is -1, and both xt and n may be different when the definition is found in compilation state; performing xt in interpretation state performs the interpretation semantics for name.

  3. The definition may be not found in interpretation state but found in compilation state, and vise versa. Also a definition may be not found at all.

An ambiguous condition exists if xt is performed in the conditions that are not met the conditions specified above.


"Performing xt" means performing the execution semantics identified by the execution token xt.


Please check the gist at github for updating and corrections in this proposal.

A definition has default interpretation semantics if and only if the "Interpretation:" section is absent in the corresponding glossary entry, and the "Execution:" section is present (see also 3.4.3.1). Default interpretation semantics for a definition is to perform its executin semantics in interpretation state (see also 3.4.3.2).

If interpretation semantics are undefined for a definition, a Forth system is allowed to provide implementation-defined interpretation semantics for this definition (see A.3.4.3.2). In such case, when the definition is found in interpretation state, performing the returned xt in interpretation state performs the implementation-defined interpretation semantics for name.

A program is allowed to apply FIND to any string. A definition may be not found by FIND even if a Forth system provides interpretation or compilation semantics for the corresponding name (for example, in the case of locals).

Reply New Version