In article <20250923222552.000054c6@tin.it>,   
   peter   wrote:   
   >On Tue, 23 Sep 2025 17:25:18 GMT   
   >anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote:   
   >   
   >> peter  writes:   
   >> >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.   
   >>   
   >> Yes, if you want to avoid that space, you lose a lot of the   
   >> interactive testing benefit.   
   >>   
   >> But at least that works on lxf64.   
   >   
   >If I do like this it works   
   >s\" \"" drop 0 rec-string Hej Peter" interpreting cr type   
   >Hej Peter ok   
   >   
   >>   
   >> >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!   
   >>   
   >> The recommendation in the proposals is that recognizers don't do   
   >> additional parsing (in order to be callable by, e.g., LOCATE or other   
   >> tools), and that the translator should do the parsing.   
   >   
   >Yes I think that would be a better solution. But it has its problems.   
   >   
   >today I have   
   >   
   >\ Recognizer for "text strings"   
   >   
   >: adj  ( len  --  len' )  \ if we are at the end of the parse area   
   >                         \ we need to adjust what we step back   
   >       source nip >in @ = + ;   
   >   
   >' noop                                    \ interpret action   
   >:noname postpone sliteral ;                \ compile action   
   >:noname postpone sliteral postpone 2lit, ; \ postpone action   
   >translator: translate-string   
   >   
   >: rec-string  ( addr len --xi | 0)   
   >       swap c@ '"' =   
   >       if adj negate >in +! (s\") translate-string   
   >       else drop 0 then ;   
   >   
   >I can easily move (s\") ( the interpretive part of S\")   
   >into the translator.   
   >But if I move also adj negate >in +! I need to send the len also.   
   >That is not as clean as doing the adjust in rec-string.   
   >   
   >Honestly I think using the string recognizer outside of recognizing   
   >is difficult.   
      
   If you want to  have quotes in a string   
   using escapes in strings is cumbersome.   
   Once you have escapes much caution is needed.   
   I adopt the convention that a double quote in a string has to   
   be doubled (aka algol 68 and other languages.)   
      
   Your example then becomes   
   s" "" rec-string Hej Peter" interpreting cr type   
   (in my book   
   """ rec-string Hej Peter" interpreting cr type  )   
      
   The implementation as a prefix " that does work in both   
   interpretation and compilation mode is :   
      
   : " 'SKIP , HERE >R 0 ,   
       BEGIN &" PARSE PP@@ DUP &" = WHILE 2DROP 1+ DUP ALLOT R@ $+! REPEAT   
       ?BLANK 0= 10 ?ERROR DROP DUP ALLOT R@ $+! ALIGN   
       R> $@ POSTPONE DLITERAL ; IMMEDIATE PREFIX   
      
   PP@@ parses a single character. SKIP (AHEAD) allows to have   
   it in a definition. I burn dictionary space for strings, even   
   in interpret mode.   
   The repeat loop immediately ends unless the next character is   
   a double quote. It should be blank, or else an exception 10   
   is thrown.   
   String operators $! $@ $+! are assumed.   
   DLITERAL is state-smart and is frowned upon.   
      
   The PREFIX is the only hook to the system, it sets a flag in the   
   header of " .   
      
      
   >peter   
   >   
   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)