From: peter.noreply@tin.it   
      
   On Sun, 21 Sep 2025 12:33:15 GMT   
   anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote:   
      
   > peter  writes:   
   > >On Sat, 20 Sep 2025 17:57:30 GMT   
   > >anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote:   
   > >   
   > >> peter  writes:   
   > >> >It has been usefull when testing new recognizers.   
   > >>   
   > >> I have been doing that by directly calling the recognizer.  E.g.   
   > >>   
   > >> s" `dup" rec-tick . .   
   > >> s" `fkjfd" rec-tick .   
   > >> s" dup" rec-tick .   
   > >   
   > >I do that also.   
   > >A bit difficult with the string recognizer!   
   >   
   > In theory:   
   >   
   > s\" \"abc\"" rec-string scan-translate-string = . type \ -1 "abc"   
   >   
   > Trying to pass the result of the REC-STRING to INTERPRETING has   
   > revealed interesting restrictions in Gforth's implementation of the   
   > results of REC-STRING:   
   >   
   > s\" \"abc\"" rec-string interpreting   
   > *the terminal*:26:25: error: Scanned string not in input buffer   
   >   
   > parse-name "abc" rec-string scan-translate-string = . type \ -1 "abc"   
   > parse-name "abc" rec-string interpreting   
   > *the terminal*:29:29: error: Invalid memory address   
   > parse-name "abc" rec-string >>>interpreting<<<   
   >   
   > - anton   
      
   This is the closest I have come   
      
   s\" \"" rec-string Hej Peter" interpreting cr type   
    Hej Peter ok   
      
   I still gives me an extra space that is needed to separate rec-string   
   from the continuation of the string. It works because rec-string does   
   the parsing of the rest of the string. If the parsing is done in   
   interpreting the string would have to be after that!   
      
   Peter   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)