From: ruvim.pinka@gmail.com   
      
   On 2024-08-07 10:11, Anton Ertl wrote:   
   > dxf  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   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)