From: peter.noreply@tin.it   
      
   On Fri, 19 Sep 2025 15:45:47 GMT   
   anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote:   
      
   > minforth  writes:   
   > >Am 17.09.2025 um 18:53 schrieb Anton Ertl:   
   > > > This posting is a more general reflection about designing types in   
   > > > Forth; it just uses recognizers as example.   
   > >   
   > >My gut feeling is that the standard Forth word zoo is already big   
   > >enough. Why should one define return types now, after more than half   
   > >a century of Forth's history? This is beyond me.   
   >   
   > There is a discussion of 0 vs. R:FAIL in at least one of the versions   
   > of Matthias Trute's proposal, and a less thorough discussion of 0   
   > vs. NOTFOUND (=R:FAIL) in Bernd Paysan's proposal.  To see an   
   > advantage of TRANSLATE-NONE (=R:FAIL=NOTFOUND), consider:   
   >   
   > : postpone ( "name" -- ) \ core   
   >     \g Compiles the compilation semantics of @i{name}.   
   >     parse-name rec-forth postponing ; immediate   
   >   
   > REC-FORTH is the system recognizer, which produces a translation (a   
   > representation of the parsed word/number/etc. on the stack).  If the   
   > recognizer does not recognize "name", it produces TRANSLATE-NONE.   
   >   
   > POSTPONING then performs the postpone action for the translation.  A   
   > straightforward implementation of translation tokens (the top cell of   
   > a translation)   
   >   
   > create translate-...   
   > ' ... , \ interpreting   
   > ' ... , \ compiling   
   > ' ... , \ postponing   
   >   
   > For TRANSLATE-NONE that would be:   
   >   
   > : undefined-word #-13 throw ;   
   >   
   > create translate-none   
   > ' undefined-word ,   
   > ' undefined-word ,   
   > ' undefined-word ,   
   >   
   > And POSTPONING can then be implemented as:   
   >   
   > : postponing ( translation -- )   
   >   2 cells + @ execute ;   
   >   
   > However, if you use 0 instead of TRANSLATE-NONE, you would have to   
   > special-case that in POSTPONING:   
   >   
   > : postponing ( translation -- )   
   >   dup 0= if -13 throw then   
   >   2 cells + @ execute ;   
   >   
   > - anton   
      
   On lxf64 each individual recognizer returns 0 when no match was found.   
   The last recognizer to be tested is REC-ABORT (same as your REC-NONE).   
   As a consequence REC-FORTH will never fail!   
   I organize the recognizers in a linked list. REC-ABORT is hard coded to always   
   be last.   
      
   The interpret word thus becomes very simple   
      
   M: STATE-TRANSLATING ( trans --  )        \ get the right xt for the current   
   state   
       2 state @  + cells+ @ execute ;   
      
   : INTERPRET2   (  -- )		   
   	begin parse-name   
   	dup while   
   		forth-recognize state-translating   
   	repeat 2drop   
       ?stack ;   
      
   BR   
   Peter   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)