Re: VALUE and TO implementation

On 2024-08-03 14:49, mhx wrote:

FORTH> 0 value _v1 immediate  ok
FORTH> : test-to 1 to _v1 ;  ok
FORTH> see test-to
Flags: TOKENIZE, ANSI
: test-to  1 TO _v1 ;  ok
FORTH> : tt test-to _v1 . ;  ok
FORTH> see tt
Flags: ANSI
$01341640  : tt
$0134164A  mov           $01341190 qword-offset, 1 d#
$01341655  push          $01341190 qword-offset
$0134165B  jmp           .+10 ( $0124A102 ) offset NEAR
FORTH> tt 1  ok
FORTH>
 FWIW.

This shows how a non-parsing "TO" in iForth passes Anton's test, doesn't it?
I can guess, "TO" in iForth changes how the Forth text interpreter translates the next lexeme.
Conceptually, something like this:
   defer translate-lexeme
   ' translate-lexeme-default is translate-lexeme
   : interpret
     begin parse-name dup if translate-lexeme repeat 2drop
   ;
   : to
     [: ( sd.name -- | x sd.name -- )
         ['] translate-lexeme-default is translate-lexeme
         find-name ?found ( nt | x nt )
         name>action(to) ( xt | x xt )
         state @ if compile, else execute then
     ;]
     is translate-lexeme
   ; immediate
A parsing "to" can be defined via this variant as follows:
   : to ( "name" -- | x "name" -- )
     ['] to execute  parse-name evaluate
   ; immediate
My "test(to)" fails to detect this implementation variant for "to" as non-parsing. A special test should be used to detect namely this variant.
Obviously, this non-parsing variant of "TO" fails when used with "execute-parsing".
A similar bug win non-parsing "[if]" and "[else]" was fixed in Gforth in 2018, see <https://github.com/forthy42/gforth/issues/16>
--
Ruvim