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?   
      
   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.   
   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]   
      
   In view of the requirement that WORD / PARSE-NAME is required to skip   
   leading delimiters this change is harmless in my opinion.   
      
   In other parsing situations (recognizers) it is no use to restrict   
   those recognizers to take care of a delimiter that is not relevant.   
   For strings only the " delimiter is relevant:   
      
   "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   
   " .   
      
      
    P.S.   
   1] Maybe still including the clarification   
   "thus removing the parsed characters"   
   but it is now largely superfluous.   
   2] I would rather see:   
   "   
   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.)   
      
   >- anton   
   Groetjes Albert   
   --   
   The Chinese government is satisfied with its military superiority over USA.   
   The next 5 year plan has as primary goal to advance life expectancy   
   over 80 years, like Western Europe.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)