From: anton@mips.complang.tuwien.ac.at   
      
   albert@spenarnc.xs4all.nl writes:   
   >In article <2026Feb9.084944@mips.complang.tuwien.ac.at>,   
   >Anton Ertl  wrote:   
   >>A more fleshed-out version of the current recognizer proposal is   
   >>online:   
   >>   
   >>   
   >>After many years this proposal is in transition from being fluid to   
   >>solid, so if you want major upheavals, I doubt that your input will be   
   >>acted upon (but you might still want to give it).  OTOH, if you find   
   >>any mistakes, missing parts or unclear parts, now is the time when   
   >>your input will be most effective.  In either case, please report any   
   >>feedback by clicking on the Reply button on the web page above.   
   >   
   >After the header Solution:   
   >"As before the text interpreter parses a white-space-delimited string. "   
   >2]   
   >   
   >What does that mean in the context of:   
   >   
   >"We gaan naar Rome" TYPE   
   >   
   >?   
   >Are there one or four delimiters in this string?   
      
   '"We' is parsed by the text interpreter and passed to a recognizer.   
   The committee has decided not to standardize the string recognizer,   
   but if it had, the specification would probably have been that   
   REC-STRING recognizes '"We' as the beginning of a string and returns a   
   translation with the translation token SCAN-TRANSLATE-STRING.  The   
   various actions of SCAN-TRANSLATE-STRING parse (right away) until the   
   corresponding closing " is found; in this case they would parse 'gaan   
   naar Rome"'.  At run-time a descriptor for the string 'We gaan naar   
   Rome' is pushed.   
      
   For more details, look at   
      
   https://net2o.de/gforth/Default-recognizers.html#index-rec_002ds   
   ring-_0028-c_002daddr-u-_002d_002d-translation-_0029-gforth_002dexperimental   
      
   and the follow the links to TRANSLATE-STRING and SCAN-TRANSLATE-STRING   
      
   >In section 3.4.1 parsing   
   >   
   >"   
   >And the number in >IN is changed to index immediately past that   
   >delimiter, thus removing the parsed characters and the delimiter from   
   >the parse area."   
   >   
   >S'"1 2 DROP" EVALUATE   
   >runs into problems with this.   
      
   I have no idea what this code is supposed to mean (it's not standard   
   code), and what problems you see with this code.   
      
   >This requires moving >IN moved past the non-existing delimiter.   
   >   
   >Wouldn't it be better to simplify this to :   
   >   
   >"   
   >And the number in >IN is changed to index immediately past the word parsed"   
   >1]   
      
   The result would be that after parsing   
      
   s" foo"   
      
   >IN would point to the second ", not behind it.  After parsing   
      
   ( a comment )   
      
   >IN would point to the ), not behind it.   
      
   >In view of the requirement that WORD / PARSE-NAME is required to skip   
   >leading delimiters this change is harmless in my opinion.   
      
   If you had pointed that out when PARSE-NAME was proposed for   
   standardization, one could have changed the proposal such that it   
   would not consume the trailing delimiter.  Unfortunately, nobody   
   pointed it out at the time, and if you wanted to propose such a change   
   now, you would have to provide very good arguments that there are no   
   programs around that rely on this behaviour.   
      
      
   >"crc.frt"   R/W    OPEN-FILE   
   >   
   >Naturally the string recognizer returns the filename, and leaves >IN   
   >pointer after the " , instead of after the first blank character after   
   >" .   
      
   In this case, the string recognizer does no parsing at all, and   
   returns a translation where the actions do not parse (the translation   
   coming out of rec-string performs parsing in its translation actions).   
      
   The text interpreter parses and consumes the space after the ".   
      
   >A recognizer leaves >N pointing after the part of the input stream   
   >that has been recognized. "   
   >How logical does that sound!   
   >(It is in fact a tautology. The position of >IN defines for all   
   >practical purposes what has been recognized.)   
      
   Actually it has been discussed whether recognizers should change >IN,   
   and the consensus among the participants was that recognizers should   
   not change >IN.  There have been suggestions of specifying that in the   
   standard, but given that nobody would want to enforce it, it was   
   decided that this should go into the rationale (note to myself: put it   
   in the rationale).  I don't remember the exact reason (I bowed out of   
   that discussion), but IIRC it has to do with using recognizers in   
   various other tools.   
      
   - 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 proceedings: http://www.euroforth.org/ef25/papers/   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)