Proposal: [129] NAME>INTERPRET wording

Informal

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

This page is dedicated to discussing this specific proposal

ContributeContributions

ruvavatar of ruv [129] NAME>INTERPRET wordingProposal2020-02-20 09:55:14

Connection of xt with interpretation semantics

The spec says that "xt represents the interpretation semantics of the word nt". But by 2.1 Definitions of terms, execution token (xt) identifies not interpretation semantics but execution semantics.

Solution

Use a wording that is slightly better harmonized with the terms definitions.

The execution token xt identifies the execution semantics that performs the interpretation semantics for the word identified by the name token nt.

Meaning of 0

It seems that the spec implies that if NAME>INTERPRET returns 0 then interpretation semantics is undefined for the corresponding word (by the premise: a specification should describe all possible variants; and the variant is only one in this case).

But actually, in some cases a Forth system just cannot provide an xt that performs the defined interpretation semantics for the corresponding word. Particularly, we can have this case when a "dual semantics" word is implemented as a STATE-dependent immediate word. Technically it is possible to return an xt (e.g. via generation of the corresponding definition on the fly), but a Forth system authors may choose to not implement such functionality.

NB: it is incorrect to return an xt that identifies STATE-depended execution semantics, when the interpretation semantics for the corresponding word don't specified as STATE-depended. Perhaps the NAME> ( nt -- xt|0 ) word from Forth-83 experimental proposals can be standardized to cover such cases. This word should return xt that identifies the execution semantics for the word identified by nt.

Solution

Explicitly mention the second meaning of 0.

If NAME>INTERPRET returns 0 then either interpretation semantics is undefined for the word identified by nt, or the system cannot provide an xt that preforms the defined interpretation semantics for this word.

ruvavatar of ruv

Without updating the meaning of returned 0 for NAME>INTERPRET, the only option for a Forth system that cannot, in some case, provide xt that performs the corresponding interpretation semantics, is to don't provide NAME>INTERPRET word at all.

AntonErtlavatar of AntonErtl

I have drafted Proposal: Reword the term "execution token (latest version) to address the execution token issue.

The interpretation semantics of a STATE-dependent immediate word is STATE-dependent. It is trivial for NAME>INTERPRET to return that. In a classic single-xt+immediate-flag system NAME>INTERPRET will never return 0. 0 allows systems with compile-only flags where the text interpreter produces an error when it encounters such a word in interpretation state (e.g., gforth-0.7).

Your proposed change makes no sense; on the usage side, it would mean that a text interpreter that uses FIND-NAME and NAME>INTERPRET is not guaranteed to work. On the implementation side, NAME>INTERPRET does not know whether a word is STATE-dependent, so it cannot return 0 for such words anyway.

ruvavatar of ruv

This proposal is not enough formal, it should be made more formal.

ruvavatar of ruvNew Version: [129] NAME>INTERPRET wording

Hide differences

Connection of xt with interpretation semantics

The spec says that "xt represents the interpretation semantics of the word nt". But by 2.1 Definitions of terms, execution token (xt) identifies not interpretation semantics but execution semantics.

Author

Solution

Use a wording that is slightly better harmonized with the terms definitions.

The execution token xt identifies the execution semantics that performs the interpretation semantics for the word identified by the name token nt.

Ruv

Change Log

Meaning of 0

2020-02-20 Initial comment for NAME>INTERPRET 2023-09-14 Make this proposal more formal

It seems that the spec implies that if NAME>INTERPRET returns 0 then interpretation semantics is undefined for the corresponding word (by the premise: a specification should describe all possible variants; and the variant is only one in this case).

Problem

But actually, in some cases a Forth system just cannot provide an xt that performs the defined interpretation semantics for the corresponding word. Particularly, we can have this case when a "dual semantics" word is implemented as a STATE-dependent immediate word. Technically it is possible to return an xt (e.g. via generation of the corresponding definition on the fly), but a Forth system authors may choose to not implement such functionality.

Currently the specification for name>interpret says that returned "xt represents the interpretation semantics of the word nt".

NB: it is incorrect to return an xt that identifies STATE-depended execution semantics, when the interpretation semantics for the corresponding word don't specified as STATE-depended. Perhaps the NAME> ( nt -- xt|0 ) word from Forth-83 experimental proposals can be standardized to cover such cases. This word should return xt that identifies the execution semantics for the word identified by nt.

Solution

But actually, in some cases a Forth system cannot provide an xt that performs the defined interpretation semantics for the corresponding word regardless of the STATE.

Explicitly mention the second meaning of 0.

Particularly, when the words like s" or to are implemented as STATE-dependent immediate words. Technically it is possible to return a correct xt according to the current specification (e.g. via generation of the corresponding definition on the fly), but it can be too burden.

If NAME>INTERPRET returns 0 then either interpretation semantics is undefined for the word identified by nt, or the system cannot provide an xt that preforms the defined interpretation semantics for this word.

Another minor problem is that it's not clear what the word represent means. According to the language of the standard, xt identifies some semantics.

Solution

The specification for name>interpret can be adjusted to solve the mentioned problem. There are two options:

  1. Allow to return 0 if the system cannot return xt that identifies the interpretation semantics for the word identified by nt

  2. Allow to return state-dependent xt, which performs interpretation semantics in interpretation state only.

Proposal

Replace the following phrase in the section 15.6.2.1909.20 NAME>INTERPRET:

xt represents the interpretation semantics of the word nt. If nt has no interpretation semantics, NAME>INTERPRET returns 0.

by the following phrase:

xt identifies the execution semantics for the word identified by nt. When this xt is executed in interpretation state, the interpretation semantics for the word is performed. If the system does not provide execution semantics for the word, NAME>INTERPRET returns 0.

ruvavatar of ruvNew Version: [129] NAME>INTERPRET wording

Hide differences

Author

Ruv

Change Log

2020-02-20 Initial comment for NAME>INTERPRET 2023-09-14 Make this proposal more formal

  • 2020-02-20 Initial comment for NAME>INTERPRET
  • 2023-09-14 Make this proposal more formal
  • 2023-09-19 Add rationale, better wording, fix some typos

Problem

Currently the specification for name>interpret says that returned "xt represents the interpretation semantics of the word nt".

Currently the specification for name>interpret says that returned "xt represents the interpretation semantics of the word nt".

But actually, in some cases a Forth system cannot provide an xt that performs the defined interpretation semantics for the corresponding word regardless of the STATE.

But actually, in some cases a Forth system cannot provide an xt that performs the defined interpretation semantics for the corresponding word regardless of STATE.

Particularly, when the words like s" or to are implemented as STATE-dependent immediate words. Technically it is possible to return a correct xt according to the current specification (e.g. via generation of the corresponding definition on the fly), but it can be too burden.

Particularly, when a word like s" or to is implemented as STATE-dependent immediate word. Technically it is possible to return a correct xt according to the current specification (e.g. via generation of the corresponding definition on the fly), but it can be too burden.

Another minor problem is that it's not clear what the word represent means. According to the language of the standard, xt identifies some semantics.

Another minor problem is that it's not clear what the term represent means. According to the language of the standard, xt identifies some semantics.

Rationale

It should be clear from the specification how, having an nt, to perform the very behavior that a Forth system performs when the Forth text interpreter encounters, in interpretation state, the name of a word identified by this nt.

Namely, to perform this behavior, must the xt returned from name>interpret be executed only interpretation state, or it may be also executed in compilation state.

Solution

The specification for name>interpret can be adjusted to solve the mentioned problem. There are two options:

  1. Allow to return 0 if the system cannot return xt that identifies the interpretation semantics for the word identified by nt
  1. Allow to return 0 if the system cannot return xt that identifies the interpretation semantics for the word identified by nt (see also the clarification re execution tokens).
    • Probably, in this case we have to introduce a word like name> (experimental in Forth-83), which returns xt that identifies the execution semantics of the word identified by nt. Since otherwise a user-defined Forth text interpreter is impossible without correct find.
  1. Allow to return state-dependent xt, which performs interpretation semantics in interpretation state only.
  1. Allow to return state-dependent xt, which performs the interpretation semantics for the word in interpretation state only.

In this proposal I stick with the second option.

If anyone prefers the first option of has other objections, please feel free to share your ideas in a comment.

Proposal

Replace the following phrase in the section 15.6.2.1909.20 NAME>INTERPRET:

xt represents the interpretation semantics of the word nt. If nt has no interpretation semantics, NAME>INTERPRET returns 0.

by the following phrase:

xt identifies the execution semantics for the word identified by nt. When this xt is executed in interpretation state, the interpretation semantics for the word is performed. If the system does not provide execution semantics for the word, NAME>INTERPRET returns 0.

xt identifies the execution semantics of the word identified by nt. When this xt is executed in interpretation state, the interpretation semantics for the word are performed. If a Forth system does not provide such execution token for the word, NAME>INTERPRET returns 0.

ruvavatar of ruvNew Version: [129] NAME>INTERPRET wording

Hide differences

Author

Ruv

Change Log

  • 2020-02-20 Initial comment for NAME>INTERPRET
  • 2023-09-14 Make this proposal more formal
  • 2023-09-19 Add rationale, better wording, fix some typos
  • 2023-09-21 Add rationale re system-defined semantics, and declare an ambiguous condition

Problem

Currently the specification for name>interpret says that returned "xt represents the interpretation semantics of the word nt".

But actually, in some cases a Forth system cannot provide an xt that performs the defined interpretation semantics for the corresponding word regardless of STATE.

Particularly, when a word like s" or to is implemented as STATE-dependent immediate word. Technically it is possible to return a correct xt according to the current specification (e.g. via generation of the corresponding definition on the fly), but it can be too burden.

Particularly, when a word like s" or to is implemented as a STATE-dependent immediate word. Technically, it is possible to return a correct xt according to the current specification (e.g. via generation of the corresponding definition on the fly), but it can be too burden.

Another minor problem is that it's not clear what the term represent means. According to the language of the standard, xt identifies some semantics.

Rationale

How to perform interpretation semantics

It should be clear from the specification how, having an nt, to perform the very behavior that a Forth system performs when the Forth text interpreter encounters, in interpretation state, the name of a word identified by this nt.

Namely, to perform this behavior, must the xt returned from name>interpret be executed only interpretation state, or it may be also executed in compilation state.

System-defined semantics

If the standard does not define interpretation semantics for a word, a Forth system may provide system-defined interpretation semantics for the word (see A.3.4.3.2).

The same is true for execution semantics — if the standard does not define them for a word, a Forth system may provide system-defined execution semantics for the word. But, due to 6.1.0070, performing these execution semantics in interpretation state must be always equivalent to performing interpretation semantics for the word (regardless whether they are standard-defined or system-defined).

Solution

The specification for name>interpret can be adjusted to solve the mentioned problem. There are two options:

  1. Allow to return 0 if the system cannot return xt that identifies the interpretation semantics for the word identified by nt (see also the clarification re execution tokens).

    • Probably, in this case we have to introduce a word like name> (experimental in Forth-83), which returns xt that identifies the execution semantics of the word identified by nt. Since otherwise a user-defined Forth text interpreter is impossible without correct find.
  2. Allow to return state-dependent xt, which performs the interpretation semantics for the word in interpretation state only.

In this proposal I stick with the second option.

In this proposal I stick to the second option.

If anyone prefers the first option of has other objections, please feel free to share your ideas in a comment.

If anyone prefers the first option or has other objections, please feel free to share your ideas in a comment.

Proposal

Replace the following phrase in the section 15.6.2.1909.20 NAME>INTERPRET:

Replace the following paragraph in the section 15.6.2.1909.20 NAME>INTERPRET:

xt represents the interpretation semantics of the word nt. If nt has no interpretation semantics, NAME>INTERPRET returns 0.

by the following phrase:

by the following paragraphs:

xt identifies the execution semantics of the word identified by nt. When this xt is executed in interpretation state, the interpretation semantics for the word are performed. If a Forth system does not provide such execution token for the word, NAME>INTERPRET returns 0.

An ambiguous condition exists in any of the following conditions:

  • interpretation semantics for the word are not defined by this standard and xt is executed;
  • execution semantics of the word are not defined by this standard and xt is executed in compilation state;

ruvavatar of ruvNew Version: [129] NAME>INTERPRET wording

Hide differences

Author

Ruv

Change Log

  • 2020-02-20 Initial comment for NAME>INTERPRET
  • 2023-09-14 Make this proposal more formal
  • 2023-09-19 Add rationale, better wording, fix some typos
  • 2023-09-21 Add rationale re system-defined semantics, and declare an ambiguous condition
  • 2023-09-22 Require xt if interpretation semantics for the word are defined by the standard

Problem

Currently the specification for name>interpret says that returned "xt represents the interpretation semantics of the word nt".

But actually, in some cases a Forth system cannot provide an xt that performs the defined interpretation semantics for the corresponding word regardless of STATE.

Particularly, when a word like s" or to is implemented as a STATE-dependent immediate word. Technically, it is possible to return a correct xt according to the current specification (e.g. via generation of the corresponding definition on the fly), but it can be too burden.

Another minor problem is that it's not clear what the term represent means. According to the language of the standard, xt identifies some semantics.

Rationale

How to perform interpretation semantics

It should be clear from the specification how, having an nt, to perform the very behavior that a Forth system performs when the Forth text interpreter encounters, in interpretation state, the name of a word identified by this nt.

Namely, to perform this behavior, must the xt returned from name>interpret be executed only interpretation state, or it may be also executed in compilation state.

System-defined semantics

If the standard does not define interpretation semantics for a word, a Forth system may provide system-defined interpretation semantics for the word (see A.3.4.3.2).

The same is true for execution semantics — if the standard does not define them for a word, a Forth system may provide system-defined execution semantics for the word. But, due to 6.1.0070, performing these execution semantics in interpretation state must be always equivalent to performing interpretation semantics for the word (regardless whether they are standard-defined or system-defined).

Connection with Tick

It we want ticking any word for which interpretation semantics are defined by the standard, name>interpret cannot return 0 for these words.

Forth systems in which name>interpret returns 0 for such a word are unknown to the author.

Solution

The specification for name>interpret can be adjusted to solve the mentioned problem. There are two options:

  1. Allow to return 0 if the system cannot return xt that identifies the interpretation semantics for the word identified by nt (see also the clarification re execution tokens).

    • Probably, in this case we have to introduce a word like name> (experimental in Forth-83), which returns xt that identifies the execution semantics of the word identified by nt. Since otherwise a user-defined Forth text interpreter is impossible without correct find.
  2. Allow to return state-dependent xt, which performs the interpretation semantics for the word in interpretation state only.

In this proposal I stick to the second option.

If anyone prefers the first option or has other objections, please feel free to share your ideas in a comment.

Proposal

Replace the following paragraph in the section 15.6.2.1909.20 NAME>INTERPRET:

xt represents the interpretation semantics of the word nt. If nt has no interpretation semantics, NAME>INTERPRET returns 0.

by the following paragraphs:

xt identifies the execution semantics of the word identified by nt. When this xt is executed in interpretation state, the interpretation semantics for the word are performed. If a Forth system does not provide such execution token for the word, NAME>INTERPRET returns 0.

xt identifies the execution semantics of the word identified by nt. When this xt is executed in interpretation state, the interpretation semantics for the word are performed.

If and only if interpretation semantics for the word are not defined by this standard and the Forth system does not provide the execution token for the word, NAME>INTERPRET returns 0.

An ambiguous condition exists in any of the following conditions:

  • interpretation semantics for the word are not defined by this standard and xt is executed;
  • execution semantics of the word are not defined by this standard and xt is executed in compilation state;

ruvavatar of ruv

If we can't assume that compile, is equivalent to lit, ['] execute compile,, then instead of the phrase:

xt is executed

we should use the phrase:

the execution semantics identified by xt are performed

I want to stick to the short wording, and assume this equivalency.

ruvavatar of ruvNew Version: [129] NAME>INTERPRET wording

Hide differences

Author

Ruv

Change Log

  • 2020-02-20 Initial comment for NAME>INTERPRET
  • 2023-09-14 Make this proposal more formal
  • 2023-09-19 Add rationale, better wording, fix some typos
  • 2023-09-21 Add rationale re system-defined semantics, and declare an ambiguous condition
  • 2023-09-22 Require xt if interpretation semantics for the word are defined by the standard
  • 2023-09-28 Add a clause re STATE-dependent execution semantics in Problem, add a section re execution of xt meaning in Rationale, better wording and formatting in some places

Problem

Currently the specification for name>interpret says that returned "xt represents the interpretation semantics of the word nt".

  1. It's currently unclear from the specification for name>interpret how to perform the interpretation semantics for the word identified by nt — namely, how to perform the behavior that a Forth system performs when the Forth text interpreter, while in interpretation state, encounters the name of a word identified by this nt (see also Rationale below).

But actually, in some cases a Forth system cannot provide an xt that performs the defined interpretation semantics for the corresponding word regardless of STATE.

  1. The specification for name>interpret says that returned "xt represents the interpretation semantics of the word nt". But actually, in some cases a Forth system cannot provide an xt that performs the interpretation semantics for the corresponding word regardless of STATE.

Particularly, when a word like s" or to is implemented as a STATE-dependent immediate word. Technically, it is possible to return a correct xt according to the current specification (e.g. via generation of the corresponding definition on the fly), but it can be too burden.

Particularly, when nt is for a word whose execution semantics depends on STATE, or for a word like s" or to, if it is implemented as an immediate word. Technically, it is possible to return a correct xt according to the current specification (e.g. via generation of the corresponding definition on the fly), but it can be too burden.

Another minor problem is that it's not clear what the term represent means. According to the language of the standard, xt identifies some semantics.

  1. A minor problem is that it's not clear what the term represent means. According to the language of the standard, xt identifies some semantics.

Rationale

How to perform interpretation semantics

It should be clear from the specification how, having an nt, to perform the very behavior that a Forth system performs when the Forth text interpreter encounters, in interpretation state, the name of a word identified by this nt.

It should be clear from the specification how, having an nt, to perform the very behavior that a Forth system performs when the Forth text interpreter, while in interpretation state, encounters the name of a word identified by this nt.

Namely, to perform this behavior, must the xt returned from name>interpret be executed only interpretation state, or it may be also executed in compilation state.

Namely, in the general case, to perform this behavior, must the xt returned from name>interpret be executed only in interpretation state, or it may be also executed in compilation state.

Execution of xt

In this proposal, the author assumes that compile, is equivalent to lit, ['] execute compile,, and therefore "xt is executed" means "the execution semantics identified by xt are performed" — no matter how — via execute directly, or as a part of execution semantics of another definition, in any nesting, when this part is appended by applying compile, to this xt.

NB: one consequence from this equivalence is that the words that operate on the return stack cannot be defined as ordinary words (see a corresponding discussion).

System-defined semantics

If the standard does not define interpretation semantics for a word, a Forth system may provide system-defined interpretation semantics for the word (see A.3.4.3.2).

The same is true for execution semantics — if the standard does not define them for a word, a Forth system may provide system-defined execution semantics for the word. But, due to 6.1.0070, performing these execution semantics in interpretation state must be always equivalent to performing interpretation semantics for the word (regardless whether they are standard-defined or system-defined).

The same is true for execution semantics — if the standard does not define them for a word, a Forth system may provide system-defined execution semantics for the word. But, due to 6.1.0070, performing these execution semantics in interpretation state must always be equivalent to performing the interpretation semantics for the word (regardless whether they are standard-defined or system-defined).

Connection with Tick

It we want ticking any word for which interpretation semantics are defined by the standard, name>interpret cannot return 0 for these words.

Forth systems in which name>interpret returns 0 for such a word are unknown to the author.

Solution

The specification for name>interpret can be adjusted to solve the mentioned problem. There are two options:

  1. Allow to return 0 if the system cannot return xt that identifies the interpretation semantics for the word identified by nt (see also the clarification re execution tokens).

    • Probably, in this case we have to introduce a word like name> (experimental in Forth-83), which returns xt that identifies the execution semantics of the word identified by nt. Since otherwise a user-defined Forth text interpreter is impossible without correct find.
  2. Allow to return state-dependent xt, which performs the interpretation semantics for the word in interpretation state only.

In this proposal I stick to the second option.

If anyone prefers the first option or has other objections, please feel free to share your ideas in a comment.

Proposal

Replace the following paragraph in the section 15.6.2.1909.20 NAME>INTERPRET:

xt represents the interpretation semantics of the word nt. If nt has no interpretation semantics, NAME>INTERPRET returns 0.

by the following paragraphs:

xt identifies the execution semantics of the word identified by nt. When this xt is executed in interpretation state, the interpretation semantics for the word are performed.

If and only if interpretation semantics for the word are not defined by this standard and the Forth system does not provide the execution token for the word, NAME>INTERPRET returns 0.

An ambiguous condition exists in any of the following conditions:

  • interpretation semantics for the word are not defined by this standard and xt is executed;
  • execution semantics of the word are not defined by this standard and xt is executed in compilation state;

ruvavatar of ruv

In the ways of execution an xt the word catch should be mentioned.


The word find (according to the proposed clarification) allows the program to check whether a word is ordinary (i.e., for which default interpretation semantics and default compilation semantics are defined): if and only if find, in interpretation state, returns -1 at the top, then the word is ordinary.

At the moment, the set of words find-name, name>interpret and name>compile does not provide a ways to check whether a word is ordinary.

Perhaps name>compile could be tightened up so that analysis its result and the results of name>interpret allows the program to conclude whether the word is ordinary.

ruvavatar of ruv

name>interpret is allowed to return 0 if interpretation semantics for the word are not defined by the standard.

But in fact, the result of 0 does not give programs any additional information, since for the same word the result can be zero in one system and non-zero in another system.

So, programs won't loose anything, and will only become simpler, if name>interpret never returns zero (i.e., if it's required to return some xt in all cases) — since programs will not need to analyze the result (e.g. before compile or execute it). Well, in some rare cases an error report shown by programs will be carried over from compile time to runtime in some systems due to this change, but anyway this report is generated at compile time only in some systems — i.e., this is a system dependent behavior that programs cannot rely on.

Suppose we changed the specification for name>interpret so that this word will require to return a system-dependent xt if interpretation semantics for the word are not defined by the standard. This change does not affect programs at all. But it affects systems — they need to be updated to comply with the new specification and new programs (which relies on the new specification).

The question is: is it acceptable to change name>interpret specification in this way, or is it better to introduce a new word for this?

The new word can be defined as follows:

: name> ( nt -- xt )
  name>interpret dup if exit then drop [: -14 throw ;]
;

Or name>interpret can be redefined in this way in a polyfill.

Reply New Version