15 The optional Programming-Tools word set

I think, "named word" is a tautology, since formally there no such thing as "not named word"; the only definition (a Forth definition) is what can be named or not named (i.e.: named definition, not named definition).

Have a look at the following definitions:

defining word: A Forth word that creates a new definition when executed.

standard word: A named Forth procedure, formally specified in this standard.

definition: A Forth execution procedure compiled into the dictionary.

word set: A set of Forth definitions grouped together in this standard under a name indicating some shared aspect, typically their common functional area.

Therefore =>

standard word: A named definition, formally specified in this standard.

Therefore =>

word: A named definition.

And the "word" term is often used in this sense (and in the standard too), but this sense is missed in the definition for the word term:

word: Depending on context, either 1) the name of a Forth definition; or 2) a parsed sequence of non-space characters, which could be the name of a Forth definition.

E.g.: "A word that returns an ior ", "defining word" — "word" here is neither (1) nor (2).

Changing the description of "nt" to the following is acceptable.

"A name token is a single-cell value that identifies a named definition."

Does it not follow then that "nt" is not a token that identifies a :NONAME definition?

@Ruvim: Yes, "a named definition" is probably a more frequently used meaning than "the name of a Forth definition". I tend to use "word" also for unnamed definitions (e.g., "of :NONAME words" below), and my impression is that others do that, too. In other words, we use "word" as synonym for "definition". Whether we want to follow this usage in the standard is up to discussion. IIRC this difference has not led to any confusion yet.

@KrishnaMyneni: There is no standard way to get an nt of a :NONAME definition, and I don't expect that there will ever be (because there are systems where there is nothing that could serve as nt of a :NONAME word).

If your question is whether the definition forbids that systems provide nts of :NONAME wordsdefinitions, the answer is no. Beyond the requirements of the standard, systems are free to provide any functionality their maintainers find appropriate. So if a system has a non-standard word for getting the nt of a :NONAME worddefinition, it's no skin off the standard's nose.

In any case, where a system does provide a 'dummy' nt for NONAME: definitions, that nt conveys no more information than that it is a member of the set of NONAME: definitions.

It makes no sense for an anonymous definition to be IMMEDIATE, or to have special compiling semantics, or a data field, or a DOES> action. All these can only be set for named definitions, Therefore, the 'most recent definition' is always the most recent named definition.

@AntonErtl, @JennyBrien: I request that you post your replies to c.l.f. also in response to the recent thread, "Clarification on CREATE and colon :". I think your replies help to lessen the confusion about the use of "nt"s in the context of :NONAME definitions, and what can be done with those "nt"s.

@AntonErtl: I agree that the standard does not prohibit creation of "nt"s for :NONAME definitions. However, I am confused about their purpose for such definitions. Is it simply to discover their existence? I think Jenny Brien's use of the term "dummy nt" to refer to them helps indicate their restricted use. In connection with a future proposal to standardize "LATEST" (or another suitable name), there appears to still be confusion on whether the returned nt should be zero in the case of the most recent definition being a :NONAME definition, or whether it should be the (non-zero) nt of the last named definition.

The original term definition can look like:

name token: A single-cell value that identifies a named word.

For comparison, a similar normative definition:

execution token: A value that identifies the execution semantics of a definition.

Possible variants

name token: A value that identifies the name of a definition.

name token: A value that identifies the name of a word.

Rationale

1. It is unclear from the glance why do we need two different identifiers for almost the same things. The proposed term definitions shows that it is the different things.
2. The size 1 cell is mentioned in the data type table, no need to mention it in the term definition.

@JennyBrien: A system that gives you some way to produce an nt for a :NONAME word can do whatever it likes, so the following is just my preference: It should return an nt for which NAME>INTERPRET produces the xt of the :NONAME word. Gforth behaves that way.

@KrishnaMyneni: There is a desire for a uniform token that represents a worddefinition (probably because in the old times, words were simple enough to be represented with a single token). Various newfangled features such as nameless definitions, dual-semantics words, or synonyms make it necessary to differentiate between xt and nt, but the desire is still there. In the new Gforth header, the idea was to make nt=xt where possible, with reasonable behaviour for words that take xts when you give them an nt that is not an xt, and reasonable behaviour for words that take nts when you give them an xt. Over the last few years we have filled various holes that still used to be there (e.g., if you use a snapshot from 2018, you cannot EXECUTE the nt of a synonym, with a recent snapshot you can). We had no particular application usage in mind, just a well-rounded system. We will see how that translates into real-world benefits.

:noname ; latest

returns 0 in Gforth, LATESTNT returns the nt of the :NONAME definition, and LATESTXT it's xt.

@Ruvim:

You want to move the first sentence of 15.3.1 into a new section "15.2.1 Definition of terms"?

The variants are nonsense. The nt does not identify the name, but the named word (or named definition, if you prefer), which (unlike the name) has an interpretation semantics and a compilation semantics.

nt and xt are different things, even in recent Gforth, which tries to make them as much the same as possible. Maybe we should add a Rationale to 15.3.1 that explains that.

You want to move the first sentence of 15.3.1 into a new section "15.2.1 Definition of terms"?

I did not think about this, but it seems reasonable — yes, but Into the existing section "15.2. Additional terms and notation". See also "16.2" for comparison.

The nt does not identify the name, but the named word (or named definition, if you prefer)

Have a look at the following definition (from "16.2")

compilation word list: The word list into which new definition names are placed.

Thanks to SYNONYM, one definition can have several names. And TRAVERSE-WORDLIST will produce different nt for each name (even for the same definition) that was placed into the word list. Therefore it is better to say that nt identifies a definition name (as a word list entry).

There is an open question about uniqueness of nt when the name and behavior are the same. Technically, SYNONYM DUP DUP can associate the same nt for newname. This situation can be detected via TRAVERSE-WORDLIST therefore it should be specified. And the answer depend on the name token term definition.

May TRAVERSE-WORDLIST produce the same nt twice (for the same or different wid) or omit the nt for some name that was placed into a word list?

You can use name>interpret to get an xt for the interpretation semantics of a word (if present).

For most words the interpretation semantics are the same as the execution semantics. For the cases where that is not the case, what's your interest in execution semantics? Especially given that you seem not to be interested in words like exit and >r where execution semantics are defined but interpretation semantics are not.

My take is that "execution semantics" for named words is only a vehicle for defining interpretation and compilation semantics through the default mechanisms in 3.4.3; that's why most words with explicitly defined interpretation and compilation semantics have no defined execution semantics. So there is no point in reifying the execution semantics in addition to interpretation and compilation semantics.

In other words, assume we introduce a name>execution. What would you use it for? Can these uses not be accomplished with name>interpret and name>compile?

that's why most words with explicitly defined interpretation and compilation semantics have no defined execution semantics.

It seems, the fact is that the different systems had the different execution semantics that is returned for these words (due to the different implementation approaches), but they implemented the same interpretation semantics and the same compilation semantics. That's why the execution semantics for such words cannot not be standardized. That's why execution semantics for them cannot be a standard vehicle for defining interpretation or compilation semantics. That's why default compilation semantics (that is based on interpretation semantics or on compilation semantics) cannot be specified in the standard.

If execution semantics for them would be specified, it restricts implementation options and makes some system non standard. I also wrote on this in length in the message news:qn0hfp$25u$1@dont-email.me "Semantics rethinking " (point 3), on 2019-09-02.

assume we introduce a name>execution. What would you use it for? Can these uses not be accomplished with name>interpret and name>compile?

I wanted to recognize only an ordinary word in the actual context. For that, I tried to implement token>xt? ( k*x td -- xt td-xt | k*x td 0 ) that extract xt of an ordinary word, or returns false otherwise (see news:rdpu54$pfn$1@dont-email.me. For that I tried to implement the name>xt? word in the following way:

: name>xt? ( nt -- xt td-xt | nt 0 )
  dup 0= if dup exit then
  dup >r name>compile ['] execute <> if
    r@ name>interpret over = if rdrop td-xt exit then
  then drop r> 0
;

Don't sure it is does what I want in any system.

Correction a typo:

"That's why default execution semantics (that are based on interpretation semantics or on compilation semantics) cannot be specified in the standard"