From: the.beez.speaks@gmail.com   
      
   On 12-02-2026 11:13, Anton Ertl wrote:   
   > Hans Bezemer  writes:   
   >> On 12-02-2026 08:24, Anton Ertl wrote:   
   >>> Gforth, iForth, and lxf included the FP wordset by default in all   
   >>> versions that I have tested.   
   > ...   
   >> Neither does 4tH. But that those are already included might be a logical   
   >> result of recognizing FP numbers in the text interpreter.   
   >   
   > Counterexample: Gforth 0.7 (before recognizers): Here the text   
   > interpreter for one word contains hard-coded stuff for dealing with   
   > words (FIND-NAME) and with single and double-cell numbers (SNUMBER?),   
   > but nothing for floating-point.  Instead, there are hooks   
   > INTERPRETER-NOTFOUND1 and COMPILER-NOTFOUND1, and when float.fs is   
   > loaded, recognizing floating-point words is added to these hooks.   
   >   
   > \ called in interpretation state   
   > : interpreter1 ( c-addr u -- ... xt )   
   >      2dup find-name dup   
   >      if   
   > 	nip nip name>int   
   >      else   
   > 	drop   
   > 	2dup 2>r snumber?   
   > 	IF   
   > 	    2rdrop ['] noop   
   > 	ELSE   
   > 	    2r> interpreter-notfound1   
   > 	THEN   
   >      then ;   
   >   
   > \ called in compilation state   
   > : compiler1 ( c-addr u -- ... xt )   
   >      2dup find-name dup   
   >      if ( c-addr u nt )   
   > 	nip nip name>comp   
   >      else   
   > 	drop   
   > 	2dup 2>r snumber? dup   
   > 	IF   
   > 	    0>   
   > 	    IF   
   > 		['] 2literal   
   > 	    ELSE   
   > 		['] literal   
   > 	    THEN   
   > 	    2rdrop   
   > 	ELSE   
   > 	    drop 2r> compiler-notfound1   
   > 	THEN   
   >      then ;   
   >   
   > The decision to not have FP in the hard-coded part of the text   
   > interpreter was taken by Bernd Paysan, so I can only guess why he did   
   > that: My guess is that this text interpreter was originally also used   
   > for Gforth EC for small CPUs without hardware FP support where Gforth   
   > does not implement FP.   
   >   
   > Another reason might be (certainly for me) that the hard-coded text   
   > interpreter is in the cross-compiled part of Gforth, whereas float.fs   
   > (which includes the thing that plugs into the text interpreter) is in   
   > the part of Gforth that is compiled with Gforth's regular compiler.  I   
   > found the latter always significantly easier to use than the   
   > cross-compiler and have always tried to keep the amount of code and   
   > changes in the cross-compiled portion of Gforth small.   
   >   
   > Counterexamples: Gforth (development), SwiftForth 4.x and VFX 5.x:   
   > Their text interpreters are recognizer-based, so recognizing FP is not   
   > hard-coded into the text interpreter at all (nor is recognizing words   
   > or integers).   
   >   
   > Concerning iForth and lxf, I don't know what they are doing, but I   
   > would not be surprised if FP is not hard-coded into their text   
   > interpreters.   
   >   
   > While I show the example above from Gforth 0.7, here are the   
   > corresponding recognizers REC-NAME and REC-NUMBER from in the current   
   > reference implementation of recognizers:   
   >   
   > : undefined-word ( -- )   
   >      #-13 throw ;   
   >   
   > ' undefined-word dup dup translate: translate-none   
   >   
   > : nop ;   
   >   
   > : lit, ( n -- )   
   >      postpone literal ;   
   >   
   > : litlit, ( n -- )   
   >      lit, postpone lit, ;   
   >   
   > ' nop ' lit, ' litlit, translate: translate-cell   
   >   
   > : 2lit, ( n1 n2 -- )   
   >      postpone 2literal ;   
   >   
   > : 2lit2lit, ( n1 n2 -- )   
   >      2lit, postpone 2lit, ;   
   >   
   > ' nop ' 2lit, ' 2lit2lit, translate: translate-dcell   
   >   
   > : name-int ( ... nt -- ... )   
   >      name>interpret execute ;   
   >   
   > : name-comp ( ... nt -- ... )   
   >      name>compile execute ;   
   >   
   > : name-post ( nt -- )   
   >      lit, postpone name-comp ;   
   >   
   > ' name-int ' name-comp ' name-post translate: translate-name   
   >   
   > : rec-name ( c-addr u -- translation )   
   >      find-name dup if   
   >          translate-name   
   >      else   
   >          drop translate-none   
   >      then ;   
   >   
   > : rec-number ( c-addr u -- translation )   
   >      snumber? case   
   >          0  of translate-none endof   
   >          -1 of translate-cell endof   
   >          translate-dcell swap   
   >      endcase ;   
   >   
   > Not shorter, but more factored, and supports postponing numbers.   
   >   
   >> Think of it:   
   >> why implement that in a CORE compiler?   
   >   
   > Are you just producing a counterargument for your claim above?   
   >   
   > - anton   
      
   Frankly, you find the same kind of setup in 4tH's "interprt.4th" library   
   routine:   
      
   \ Define ABORT routine, simply print offending word   
   defer NotFound   
   :noname type [char] ? emit space ; is NotFound   
      
   However, this one is used to define custom interpreters - not to define   
   a REPL as front end for the language. It doesn't compile anything   
   either. Usually "NotFound" is used to define custom error handling.   
      
   Hans Bezemer   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)