From: peter.noreply@tin.it   
      
   On Sat, 20 Sep 2025 16:08:03 GMT   
   anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote:   
      
   > peter  writes:   
   > >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).   
   > >>=20   
   > >> 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:   
   > >>=20   
   > >> : rec-none ( c-addr u -- translation )   
   > >>     2drop translate-none ;   
   > >>=20   
   > >> I doubt that your REC-ABORT works like that.  My guess is that your   
   > >> REC-ABORT is:   
   > >>=20   
   > >> : rec-abort -13 throw ;   
   > >   
   > >:NONAME  -13 throw ;=20   
   > >dup-t   
   > >dup-t   
   > >CREATE TRANSLATE-ABORT   
   > >,-d-t ,-d-t ,-d-t   
   > >   
   > >   
   > >: REC-ABORT ( addr len -- nt)   
   > >    >msg translate-abort ;   
   >   
   > Ok, your TRANSLATE-ABORT is TRANSLATE-NONE, and your REC-ABORT is   
   > REC-NONE.   
   >   
   > >>msg saves the string to be able to print the name in the abort message   
   >   
   > Might be cleaner than Gforth's current mechanism (I don't remember how   
   > that works).   
   >   
   > >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.   
   >   
   > So the usual recognizers return 0 for not-recognized, but REC-FORTH   
   > returns TRANSLATE-NONE.  Interesting twist.  What about other   
   > recognizer sequences?   
      
   There are no other recognizer sequences. I have not found a use case for that.   
   I guess I would implement them to also return TRANSLATE-NONE.   
      
      
   >   
   > >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.   
   >   
   > The standard does not mandate any particular implementation of   
   > REC-FORTH or of recognizer sequences.   
   >   
   > >   
   > >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   
   >   
   > But before other recognizers behind the number recognizers?   
      
   Yes   
      
   >   
   > >- Executing it moves the recognizers to the top of the list   
   >   
   > I am confused.  Under what circumstances does the "insert just behind"   
   > happen, and when "move to the top"?   
      
   Insert behind only when the recognizer is created. To still have a standard   
   system.   
   To the top in all other cases.   
   ONLY for example contains   
      
   : ONLY ( -- )   
       1 #order !  root-wordlist context !   
       number-recognizer word-recognizer locals-recognizer ;   
      
   >   
   > And what scenario do you have in mind that makes this behaviour   
   > useful?   
      
   It has been usefull when testing new recognizers.   
   Otherwise I never change the ordering   
      
   Peter   
      
      
   >   
   > - anton   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)