From: peter.noreply@tin.it   
      
   On Sat, 20 Sep 2025 07:25:54 GMT   
   anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote:   
      
   > peter  writes:   
   > >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).   
   >    
   > REC-NONE is the neutral element of recognizer sequences, i.e., as far   
   > as the sequence is concerned, a noop.  You can prepend REC-NONE to a   
   > recognizer sequence and the sequence will produce the same result.   
   > The implementation of REC-NONE is:   
   >    
   > : rec-none ( c-addr u -- translation )   
   >     2drop translate-none ;   
   >    
   > I doubt that your REC-ABORT works like that.  My guess is that your   
   > REC-ABORT is:   
   >    
   > : rec-abort -13 throw ;   
      
   :NONAME  -13 throw ;    
   dup-t   
   dup-t   
   CREATE TRANSLATE-ABORT   
   ,-d-t ,-d-t ,-d-t   
      
      
   : REC-ABORT ( addr len -- nt)   
       >msg translate-abort ;   
      
   The -t and -d-t endings are due to this being metacompiled   
   >msg saves the string to be able to print the name in the abort message   
      
   >    
   > and I will work with that guess in the folloing.   
   >    
   > >As a consequence REC-FORTH will never fail!   
   >    
   > In the proposal, any recognizer and recognizer sequence, including   
   > that in REC-FORTH, can have TRANSLATE-NONE as a result, which   
   > indicates that the recognizer (sequence) did not recognize the string.   
   >    
   > >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 ;   
   >    
   > The same implementation can be used with the proposal (but it calls   
   > FORTH-RECOGNIZE by a new name: REC-FORTH) and TRANSLATE-NONE.   
   > Compared to what I presented, the order of xts in the   
   > TRANSLATE-... tables is reversed, so POSTPONING would become even   
   > simpler:   
   >    
   > : POSTPONING ( translation -- )   
   >   @ execute ;   
      
   : postpone ( "name" -- )	   
   	parse-name forth-recognize @ execute ; immediate   
      
   >    
   > One difference is that, for an unrecignized string, the -13 throw is   
   > done later, when performing the action of the translation.   
   >    
   > The benefit of having TRANSLATE-NONE and doing the -13 throw in its   
   > actions, instead of hard-coded in REC-FORTH is that REC-FORTH contains   
   > just another recognizer sequence, that recognizer sequences behave   
   > like recognizers, and thus are nestable, and that you can write code   
   > like   
   >    
   > ( c-addr u ) rec-something ( translation ) postponing   
   >    
   > and it will work without you having to put REC-ABORT at the end of   
   > REC-SOMETHING.   
   >    
   > However, the current proposal does not propose to standardize   
   > POSTPONING etc., but leaves it to the standard text interpreter and   
   > standard POSTPONE to perform the translation actions.  So, as long as   
   > we don't standardize these words, one could also have a recognizer   
   > sequence   
   >    
   > ' rec-abort ' rec-forth 2 recognizer-sequence: rec-forth-abort   
   >    
   > and let the text interpreter and POSTPONE call REC-FORTH-ABORT instead   
   > of REC-FORTH.  But if we want to leave the option open to standardize   
   > POSTPONING etc. in the future, the proposed approach is more flexible.   
   >    
   > - anton   
      
   Apart from the names that has changed (I have not updated them yet) I see only   
   minor differences. One being the individual recognizer returning 0 on fail.   
      
   I implemented yur proposal from February and it has worked as expected.   
   The float recognizer has been a cleanup removing deferred words and now done   
   instead when the float package is included.   
      
   I am using a linked list of recognizers but that is only an implementation   
   detail.   
   I do not see that the "standard" would mandate an array.   
      
   I have introduce a vocabulary like word for managing the recognizers   
      
   It looks like   
      
   ' rec-local recognizer: Locals-recognizer   
      
   This does 3 things   
      
   - It gives the recognizer a name.   
      
   - It inserts the recognizer in the list just behind the number recognizers   
      
   - Executing it moves the recognizers to the top of the list   
      
   I have also adjuster ORDER to also chow the recognizers   
      
   order   
     Order: $0070´01C0 Forth   
            $0070´01E8 Root   
      
   Current: $0070´01C0 Forth   
      
   Loaded recognizers:   
            $0070´18E8 Locals-recognizer   
            $0070´0648 Word-recognizer   
            $0070´0620 Number-recognizer   
            $0070´1C88 Float-recognizer   
            $0070´1D28 String-recognizer   
            $0070´19B0 Tick-recognizer   
            $0070´1948 To-recognizer   
            $0070´1970 To2-recognizer   
            $0070´1A20 Only-recognizer   
            $0070´0600 Abort not found   
      
   ok   
      
   BR   
   Peter   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)