Terms definitions and data types, v01

[ruv]

The draft for the terms and data types:

• the last version
• the commits list to make review and add notes.
• the version published at forth-standard.org

See also: comparison to some past proposals.

Rationale

Using of "data type" term

See also data type term in 2.1 Definitions of terms and 3.1 Data types

Lexical context

The same lexeme may have the different semantics in the different states for the system. For example, a lexeme can be resolved into the different words depending on the search order, or into the different numbers depending on the current BASE value. (This subject was also addressed in length in the message news:[email protected] (raw) "Recognizers terminology" on 2020-06-26)

Translation

At the moment, to translate term is only used to simplify other definitions. Also, it much helps in discussions, when an actual operation (interpretation or compilation) does not matter.

Connection with POSTPONE

There is no need to mention a postpone action or something alike in token descriptor or token itself. Formally, POSTPONE just needs to know compilation semantics, and a token determines them.

Some choices consideration

• Perhaps some term are superfluous, or other terms missed. But the first question is correctness, and the second is reasonableness in linking a term and its meaning.

• blank character or space character or white space?

• Perhaps it's worth to use another term instead of "token". Perhaps the general "tuple" is enough.

• Is it worth to use just "descriptor" instead of "token descriptor" ?

• "default perceptor" or "initial perceptor"?

• tuple of data objects or sequence of data objects? It seems, tuple is more abstract term, while sequence has some connotation to contiguity (or the same logical location of the items) and to less limited length.

• A successful result of a single call to find is not a token in the general case (according to the current definition), since on some systems this result might determine either interpretation semantics or compilation semantics depending on the STATE value at the time of the call. Is it acceptable? If we allow a such result to be a token, an ambiguous condition will exist on translating this token in some cases. See also my FIND clarification proposal.
  OTOH if we will not provide a way to translate a token, this nuance does not matter.

[ruv]

"Dynamic context" is too wide (too pervasive) notion in Forth, and too close to "dynamic scope" notion.

Let's use "lexical context" term to denote the part of the system state the recognizers depends on.

(all mentions have been updated)