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,927 of 117,927   
   Krishna Myneni to Anton Ertl   
   Re: Recognizer proposal   
   24 Feb 26 02:43:54   
   
   From: krishna.myneni@ccreweb.org   
      
   On 2/21/26 9:40 AM, Anton Ertl wrote:   
   > minforth  writes:   
   >> This is not the time or place for criticism.   
   >   
   > I think it is time for criticism, particularly meaning 2 of   
   >  (meaning 1 is not clear to   
   > me).  Concerning the place, giving your feedback on   
   >    
   > would be ideal, because that provides the versions of the proposal and   
   > the feedback in one place.   
   >   
   >> Everyone must decide for   
   >> themselves whether this flavour of recognisers is useful for their   
   >> applications.   
   >   
   > Yes, and system implementors have to decide whether the want to   
   > implement it.   
   >   
      
   My initial study of the recognizer proposal, and first steps to   
   implement it in kForth-64, have led to a few observations:   
      
   1. To first order, implementing essential recognizers, minus the ability   
   to set them, amounted to a refactoring of existing code in the Forth   
   interpreter/compiler. I began by factoring out the word INTERPRET, which   
   appeared in Starting Forth by Brodie, from the interpreter/compiler code   
   and, from there, identifying the parts of it which mapped to REC-NAME,   
   REC-NUMBER, and REC-FLOAT.   
      
   2. It was a simple matter to factor words, REC-NAME, REC-NUMBER, and   
   REC-FLOAT (kForth doesn't have locals so REC-LOCAL wasn't necessary at   
   the present time) from INTERPRET though the return values aren't yet   
   consistent with the proposal. One has to first understand the   
   non-obviously-named TRANSLATE-XXX words.   
      
   3. It took me a little while to wrap my head around what TRANSLATE-XXX   
   words were doing, but finally figured out that they were data structures   
   providing execution semantics for different values of STATE. For   
   recognizing words, TRANSLATE-NAME mapped to code used by the kForth   
   interpreter called ExecutionMethod(), changed recently to   
   GetExecutionSemantics().   
      
   The next step is to replace GetExecutionSemantics() by TRANSLATE-NAME.   
   This is a bit more complex in kForth, which allows deferred execution   
   (essentially noname compilation) during interpretation, but it is   
   possible for the recognizer REC-NAME to provide a TRANSLATE-NAME   
   compatible with the recognizer proposal.   
      
      
   This is where I stand after a week of studying and gradually   
   transforming kForth to implement recognizers. For me, the process   
   requires repeating all system tests prior to each commit. It's a tedious   
   process but necessary to keep a working Forth system while the revisions   
   are made -- I could use a stable older version of kForth-64 for running   
   my applications, but the applications provide additional checks on   
   whether the revisions have broken anything.   
      
   --   
   Krishna   
      
   --- 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