Proposal: Reword the term "execution token"

Do you consider using the "execution token" term in all other places? Or only in the glossary for FIND?

What is a rationale to change this term instead of making correction in FIND?

It seems to me, the "execution token" term is excellent as identifier of execution semantics.

1. A "code that can be EXECUTEd" is actually some definition.

definition: A Forth execution procedure compiled into the dictionary.

One anonymous definition can perform interpretation semantics for other named definition.

2. The wording "can be EXECUTEd" seems to be far from the language of standard.

Yes, it's exactly because I consider all the places where xt occurs that I think it's inadequate to restrict xt to only refer to execution semantics. On the producer side, ' ['], NAME>INTERPRET, NAME>COMPILE come into my mind from the top of my head. On the consumer side, EXECUTE and COMPILE, should not be limited to performing execution semantics. With a restricted xt, you would have to work around that by revising at least all the producers.

xt will continue to be an identifier of execution semantics. With the new wording we can also identify other semantics, and actually the standard has done that all along; it's just that the definition of the term "execution token" did not fit with that usage. This proposal is proposing to fix that.

The wording of the new definition has been hashed out in the committee meeting and I will post a new version of the proposal with the new wording soon.

that I think it's inadequate to restrict xt to only refer to execution semantics.

I thought about this problem. And I came to the following reasoning.

Have a look at the following example:

: foo postpone if ;
: bar foo ;
' foo ( xt-foo )
' bar ( xt-bar )

xt-bar identifies the execution semantics for bar. But these semantics are equivalent to the execution semantics for foo. Then, xt-bar also identifies the execution semantics for foo.

Then, xt-foo and xt-bar identify the same execution semantics (and they even may be equal, according to 3.1.3.5 Execution tokens).

But the execution semantics for foo are equivalent to the compilation semantics for if. Then xt-foo also identifies the compilation semantics for if. And performing the execution semantics identified by xt-foo is equivalent to performing the compilation semantics for if.

But you claim that an execution token cannot identify compilation semantics. What is wrong?

My conclusion is that any execution token always identifies some execution semantics, and at the same time it identifies any other semantics that are equivalent to these execution semantics.

I.e., an execution token cannot identify only some compilation semantics alone, but it identify execution semantics and the compilation semantics that are equivalent to these execution semantics.

So we may say that an execution token identifies some compilation semantics (for example), but it shall imply that this execution token also identifies the equivalent execution semantics, and when execute is applied to this token, these execution semantics are performed. Ditto for compile,.

If an xt identifies some interpretation semantics, it just means that it identifies the execution semantics that are equivalent to these interpretation semantics.

Therefore, we don't have any problems on the side of execution token consumers.

Concerning the producers side

1. NAME>COMPILE specification doesn't imply that the returned xt identifies something other then some execution semantics.

2. NAME>INTERPRET specification can use "identify" instead of represent: "xt identifies the execution semantics that are equivalent to the interpretation semantics for the word nt". But it still doesn't mean that it returns the same value that Tick returns for the same word.

3. Tick (both ' and [']) implies that the returned xt identifies the execution semantics for the word in the argument. My proposal fixes some edge cases of using Tick.

4. The term "execution token" is correctly used in FIND (at least, it's correct for single-xt systems, and acceptable for dual-nt systems), but single-nt+dual-xt Forth systems don't exactly reflect specification of FIND. So, FIND should be updated in this regard, since "its execution token xt" sometimes is not correct in single-nt+dual-xt systems.

Problem with "executable code"

5. Do we have non executable code?

6. "Executable code" doesn't have any connection with semantics. It looks like a model of a far lower level.

7. Tick returns "the execution token for name", that means an identifier of the execution semantics for name. So applying execute to this xt performs the execution semantics for name. After the proposed update, Tick returns an identifier of some "executable code" for name. When execute is applied to this xt, what semantics are performed? It's unclear.

In my comment I showed that we don't have a problem that was pointed out.

If we don't have counter arguments on that, why do we need this change at all?

The point of the definition of terms is to paint a broad picture of what these terms mean. Providing a misleading definition is contrary to that point, even if you can argue that the definition is (or at least can be interpreted as) technically correct, and those who were misled by it only misunderstood it. The bottom line is that a definition that is misunderstood is a bad definition. And in the present case the old definition has led to misunderstandings, so revising it is well justified.

Accepted with vote #21 12Y:0:0

Accepted with vote #21 12Y:0:0

It seems, the new definition introduces more problems than it allegedly solves.

The proposed variant:

execution token: A value that can be passed to EXECUTE (6.1.1370)

has the following problems.

1. This basic definition Inalienably refers to the Forth word EXECUTE. It either means that there is a lack of terms and the terminology should be better developed, or that just this definition is too poor. In any case, by this factor the new definition worse than the old one.

2. This definition is indirectly recursive via the data type symbol xt. Just ask what a value, according to 6.1.1370, can be passed to EXECUTE? — an execution token only!

3. This definition introduces a new lacuna into the normative text. The glossary entry 6.1.1370 EXECUTE says that EXECUTE performs the semantics identified by xt, but now the standard nowhere says that an xt value (a value of the corresponding data type "execution token") identifies semantics, and what semantics.

A more detailed explanation of the item 2.

A value that can be passed to EXECUTE is limited by the data type that has the symbol xt. This symbol is dedicated for the data type "execution token" (see 3.1 Data types). According to the the old definition, a value of this data type identifies execution semantics. But according to the new definition, a value of this data type is a value that can be passed to EXECUTE, i.e., the value, that has the data type symbol xt, i.e., that has the data type "execution token".

Thus, by the new definition, "execution token" is a value that is an execution token. Perfect tautology! This "definition" just says nothing.

A term definition that defines nothing is a confusing definition, so it's a bad definition.

It's a mistake that the new version of this proposal was not publicly discussed before voting (and a time was not provided for that). I can't find a fair explanation why all 12 TC members, without exclusions, voted for this version. Probably, due to some circumstances, the most TC members voted by a blind confidence, without enough immersing into the problem. I'm sorry.