Proposal: Reword the term "execution token"

Formal

This page is dedicated to discussing this specific proposal

ContributeContributions

AntonErtlavatar of AntonErtl Reword the term "execution token"Proposal2020-09-03 11:55:03

Author:

M. Anton Ertl

Change Log:

Problem:

The definition of the term "execution token" does not match its usage in FIND.

Solution:

Change the wording of the definition of the term to match the usage.

Proposal:

In Section 2.1, change:

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

into

execution token: A value that identifies code that can be EXECUTEd, e.g., for the interpretation semantics of a word.

ruvavatar of ruv

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.

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

AntonErtlavatar of AntonErtl

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.

AntonErtlavatar of AntonErtlNew Version

Hide differences

Author:

M. Anton Ertl

Change Log:

2020-09-03 Hashed out the new wording in a committee meeting.

Problem:

The definition of the term "execution token" does not match its usage in FIND.

The definition of the term "execution token" does not match its usage in FIND, ', ['], NAME>INTERPRET, NAME>COMPILE.

Solution:

Change the wording of the definition of the term to match the usage.

Proposal:

In Section 2.1, change:

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

into

execution token:

A value that identifies code that can be EXECUTEd, e.g., for the interpretation semantics of a word.

A value that identifies executable code.

Formal

ruvavatar of ruv

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"

  1. Do we have non executable code?

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

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

Reply New Version