Extended semantics of [COMPILE]

[ruv]

Problem

In contrast to POSTPONE, it is difficult to extend the semantics of [COMPILE] to any lexeme.

Let's consider a phrase [COMPILE] 123. Conceptually, it should be equivalent to the phrase 123.

But the specification for [COMPILE] refers to the "default compilation semantics" term, that in turns refers to the "execution semantics" term. And "execution semantics" take place for the Forth definitions only (at the moment). So, if a token is not for a Forth definition, it does not have "Execution" section (in the corresponding glossary entry), and hence it cannot have default compilation semantics, and hence it should have non default compilation semantics.

And [COMPILE] 123 will be equivalent to POSTPONE 123 (i.e. 123 LIT,) — that is quite unexpected.

Solution 1

(just an idea)

It is need to specify the "Execution" section for some lexemes that are not Forth words.

E.g.

If a lexeme is recognized as a token x with td-lit descriptor,

Execution: place x to the data stack.

Another problem

Tick is applicable if Execution is specified and Interpretation is not specified (i.e. default interpretation semantics). But it should not be applicable for numbers (as an example).

Workaround

Use a dummy Interpretation section. E.g.:

Interpretation: perform the execution semantics given bellow.

Execution: place x to the data stack.

(It's a bad solution, since even if formally it's not default interpretation semantics, actually it's default interpretation semantics)

Solution 2

Change specification for [COMPILE]:

If name has other than default compilation semantics and its compilation semantics is not equivalent to appending interpretation semantics to the current definition [...]

(It's a bad solution, since we should refer to "run-time semantics", instead of "interpretation semantics").

Solution 3

Just let's allow to apply [COMPILE] to Forth words only.

If [COMPILE] is applied to a lexeme that is not resolved into a Forth word then: if the Exception word set is present, throw the exception -32 "invalid name argument", otherwise an ambiguous condition exists.

Another solution

Make [COMPILE] obsolescent (and unfindable) if the Recognizer word set is provided.

The best solution

If a Forth system will be able to postpone any fragment of code, neither [COMPILE] nor POSTPONE semantics are demanded to be extended.

c{ ccc }c (proof of concept: c-state)

Execution: append run-time semantics of ccc to the current definition.
(actually, the case of c{ if }c is harder to specify).

Run-time semantics

Unless otherwise specified in the "Run-time:" section of the glossary entry, the run-time semantics of a Forth definition are its execution semantics.

[ruv]

There is another big problem with [COMPILE], see a comment at forth-standard.org.

It looks like the best way is to don't provide [COMPILE] at all.

[ruv]

I no longer consider possible implementations of [compile] (according to Forth-2012) due to its inherent design flaw.

The word [compile] cannot be correctly applied to the words like exit, >r, etc (i.e., the words having formal default compilation semantics, and undefined interpretation semantics), if they are redefined by the user, since the user can only define special compilation semantics for them.

NB: if >r is implemented as an ordinary word, then compile, can be applied to >r by the Forth text interpreter , and then compile, is not equivalent to postpone literal postpone execute in the general case, since execute may place some data objects on the return stack before executing the xt (and also remove them from the return stack after that).