15 The optional Programming-Tools word set

15.1 Introduction

This optional word set contains words most often used during the development of applications.

15.2 Additional terms and notation

None.

15.3 Additional usage requirements

15.3.1 Data types

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

Append table 15.1 to table 3.1.

Table 15.1: Data types

Symbol Data type Size on stack

nt name token 1 cell

See: A.15.3.1 Name tokens.

15.3.2 The Forth dictionary

A program using the words CODE or ;CODE associated with assembler code has an environmental dependency on that particular instruction set and assembler notation.

Programs using the words EDITOR or ASSEMBLER require the Search Order word set or an equivalent implementation-defined capability.

See: 3.3 The Forth dictionary.

15.4 Additional documentation requirements

15.4.1 System documentation

15.4.1.1 Implementation-defined options

15.4.1.2 Ambiguous conditions

15.4.1.3 Other system documentation

  • no additional requirements.

15.4.2 Program documentation

15.4.2.1 Environmental dependencies

15.4.2.2 Other program documentation

  • no additional requirements.

15.5 Compliance and labeling

15.5.1 Forth-2012 systems

The phrase "Providing the Programming-Tools word set" shall be appended to the label of any Standard System that provides all of the Programming-Tools word set.

The phrase "Providing name(s) from the Programming-Tools Extensions word set" shall be appended to the label of any Standard System that provides portions of the Programming-Tools Extensions word set.

The phrase "Providing the Programming-Tools Extensions word set" shall be appended to the label of any Standard System that provides all of the Programming-Tools and Programming-Tools Extensions word sets.

15.5.2 Forth-2012 programs

The phrase "Requiring the Programming-Tools word set" shall be appended to the label of Standard Programs that require the system to provide the Programming-Tools word set.

The phrase "Requiring name(s) from the Programming-Tools Extensions word set" shall be appended to the label of Standard Programs that require the system to provide portions of the Programming-Tools Extensions word set.

The phrase "Requiring the Programming-Tools Extensions word set" shall be appended to the label of Standard Programs that require the system to provide all of the Programming-Tools and Programming-Tools Extensions word sets.

15.6 Glossary

15.6.1 Programming-Tools words

15.6.2 Programming-Tools extension words

ContributeContributions

KrishnaMyneniavatar of KrishnaMyneni description of "nt" in the standardRequest for clarification2019-08-25 21:58:52

Background

In the optional Programming Tools wordset the following description is given in 15.3.1 for the data type "name token":

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

Following this description, the stack diagram abbreviation "nt" is assigned to "name token" in Table 15.1.

Problem

The description "name token" is not a good match for a value which identifies a named word. "Name token" suggests a value associated with the name data of the word, i.e. the string representation of the word name, rather than a value which may be used more generally to obtain available information in the dictionary about a named word. Often this information is called the header data, or simply the header, for a word. The intent of the description in 15.3.1 is to make an association between a "name token" and a named-word, in contrast to an unnamed-word, rather than to restrict which header data may be obtained from the token.

Proposal

Replace use of the term "name token" with "named-word token" to represent more precisely the quantity abbreviated as "nt" throughout the text of the standard. Also include a definition of the term, "named-word token," in section 2.1, "Definition of terms".

ruvavatar of ruv

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

KrishnaMyneniavatar of KrishnaMyneni

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?

AntonErtlavatar of AntonErtl

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

JennyBrienavatar of JennyBrien

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.

KrishnaMyneniavatar of KrishnaMyneni

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

ruvavatar of ruv

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.

AntonErtlavatar of AntonErtl

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

ruvavatar of ruv

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?

Reply New Version

ruvavatar of ruv Same name token for different wordsProposal2020-06-09 16:36:22

This contribution has been moved to the proposal section.

GeraldWodniavatar of GeraldWodni

This reply has been moved to the proposal section.

ruvavatar of ruv

This reply has been moved to the proposal section.

ruvavatar of ruv

This reply has been moved to the proposal section.

JennyBrienavatar of JennyBrien

This reply has been moved to the proposal section.

AntonErtlavatar of AntonErtl

This reply has been moved to the proposal section.
Reply New Version

ruvavatar of ruv Getting execution semantics from nt Request for clarification2020-08-29 08:10:26

How can we conclude from nt, do identifiable execution semantics are defined for the corresponding definition? And how to get the corresponding xt, if any?

By "identifiable" I mean that these semantics may be identified by an execution token xt — to exclude the cases of the words like EXIT, >R, etc, that have only nominal execution semantics (see also news:r2u5p3$n4p$1@dont-email.me).

AntonErtlavatar of AntonErtl

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?

ruvavatar of ruv

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.

ruvavatar of ruv

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"

Reply New Version