Interpretation semantics (was: VALUE and TO implementation)

On 2024-08-07 10:11, Anton Ertl wrote:

dxf <dxforth@gmail.com> writes:

On 6/08/2024 2:27 pm, dxf wrote:

...
ISTR dual-xt solutions also have problems with 'edge cases'.

>
Works for state-smart but not dual-xt:
>
  : ,"  postpone s"  dup c,  here  over allot  swap cmove ;
>
  ," Hello world"

 I did not understand at first what this code was supposed to do, in
particular why you would want to perform the compilation semantics of
S" outside a colon definition.
 After some thinking I found that this code actually relies on a buggy
implementation of S" which does not implement the compilation
semantics of the standard S" in this usage.

I would say, this code actually relies on a buggy implementation of `postpone`  ;-)

It's better to write code that does not rely on such bugs:
 : ,"  ['] s" execute  dup c,  here  over allot  swap cmove ;
 ," Hello world"

A portable implementation that behaves the same on almost any Forth system regardless of the current STATE:
   : ,"  ['] s" execute-interpreting
       dup c,  here  over allot  swap cmove ;
where
   : compilation  ( -- flag )  state @ 0<> ;
   : enter-compilation  ( -- )           ] ;
   : leave-compilation  ( -- )  postpone [ ;
   : execute-interpreting ( i*x xt --j*x )
     compilation 0=  if  execute  exit  then
     leave-compilation  execute  enter-compilation
   ;
This approach also works for any immediate word when you want to perform the interpretation semantics of this word — the behavior observed when the Forth text interpreter encounters the word in interpretation state.
Regarding terminology.
If by "interpretation semantics" we mean such behavior that, for the case of an immediate word, is always equal to the execution semantics of this word (meaning 2), then we will need *another* term to refer the very behavior observed when the Forth text interpreter encounters the word in interpretation state (meaning 1).
But there is no particular point in introducing another term, since the term for the meaning 2 is not needed at all! Neither in formalization, no in practice. But the meaning 1 is required.
Therefore, by "interpretation semantics" we should always imply the meaning 1, and never imply the meaning 2.
Note. It's easy to define such a word `foo` that its execution semantics, identified by the phrase:
   ['] foo
are *not* equal to the execution semantics identified by the phrase:
   [: ['] foo execute-interpreting ;]
Normatively, the interpretation semantics for the word `foo` is equal to the execution semantics identified by the latter phrase.
--
Ruvim