home bbs files messages ]

Forums before death by AOL, social media and spammers... "We can't have nice things"

   comp.lang.forth      Forth programmers eat a lot of Bratwurst      117,927 messages   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]

   Message 117,553 of 117,927   
   Anton Ertl to peter   
   Re: 0 vs. translate-none   
   20 Sep 25 16:08:03   
   
   From: anton@mips.complang.tuwien.ac.at   
      
   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?   
      
   >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?   
      
   >- 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"?   
      
   And what scenario do you have in mind that makes this behaviour   
   useful?   
      
   - anton   
   --   
   M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html   
   comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html   
        New standard: https://forth-standard.org/   
   EuroForth 2025 CFP: http://www.euroforth.org/ef25/cfp.html   
   EuroForth 2025 registration: https://euro.theforth.net/   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]


(c) 1994,  bbs@darkrealms.ca