Re: single-xt approach in the standard

On 2024-09-18 14:34, Ruvim wrote:

On 2024-09-17 23:12, Anthony Howe wrote:

[...]

what I don't get is how for a dual-xt system you define a single word with two actions for interpret and compile. I don't see a word to distinguish between the two, except maybe IMMEDIATE.
>

[...]

Do you define the same word twice, once for compile (immediate) and again for interpret (order of definitions should not be important). Example:
>
: s" ( "ccc" -- sd | ) postpone sliteral ; immediate
: s" ( "ccc" -- sd | ) dup >r allocate throw tuck r@ move r> ;

 Namely this cannot be standard compliant. But yes, something similar. There are different ways in different systems.
 For example, it might look like this:
    : s" ( "ccc<quot>" -- ) postpone sliteral ; immediate
    interpret: s" ( "ccc<quot>" -- sd )
     dup >r allocate throw tuck r@ move r>
   ;
 or
    interp: s" ( "ccc<quot>" -- sd )
     dup >r allocate throw tuck r@ move r>
   ;interp

Typo: parsing is missed.
Correction:
   : s" ( "ccc<quot>" -- ) '"' parse postpone sliteral ; immediate
   interpret: s" ( "ccc" -- sd )
     '"' parse
     dup >r allocate throw tuck r@ move r>
   ;

  Where (in a classic single-xt system):
    : interpret: ( "<spaces>name" -- colon-sys )
     parse-name get-current search-wordlist
     dup 0 = abort" (not found; comp semantics must be defined first)"
        -1 = abort" (the found word is not immediate)"
     ( xt.compilation ) build-interpretation-slot ( a-addr )
     >r depth >r :noname ( xt colon-sys ) r> 1- roll r> !
   ;
    : obtain-interpretation ( xt1 -- xt1 | xt2 )
     dup lookup-interpretation-slot dup if nip @ exit then drop
   ;
    : find ( c-addr -- c-addr 0 | xt 1 | xt -1 )
     find dup if dup 1 = if state @ 0= if
       >r obtain-interpretation r>
     then then then
   ;
    : name>interpret ( nt -- xt|0 )
     name>interpret obtain-interpretation
   ;
  And this makes a classic single-xt system a dual-xt system.
 But we still have to execute the result of "name>interpret" *only* in interpretation state if we want to perform the interpretation semantics of the word.  Because we don't know whether the execution semantics identified by the returned xt depend on STATE.  And if they depend, we must execute them in interpretation state to perform the interpretation semantics.
 Therefore, having a second xt gives us little benefit.
 NB: when we want to perform the interpretation semantics for a word, we want to perform *exactly* the behavior that the system exhibits when the name of that word is encountered by the Forth text interpreter in interpretation state.  There are no examples yet where we need anything else.
  -- Ruvim