From: the.beez.speaks@gmail.com   
      
   On 27-04-2025 14:02, albert@spenarnc.xs4all.nl wrote:   
   > In article ,   
   > Hans Bezemer   wrote:   
   >> On 27-04-2025 08:21, dxf wrote:   
   >>> On 26/04/2025 9:07 pm, albert@spenarnc.xs4all.nl wrote:   
   >>>> In article ,   
   >>>> dxf   wrote:   
   >>>>> On 26/04/2025 2:34 am, Hans Bezemer wrote:   
   >>>>>> ...   
   >>>>>> Yeah, I have helped to make a proposal for PLACE and +PLACE - which   
   never even made it to the voting stage.   
   >>>>>   
   >>>>> It's a nice symmetry.  OTOH the remaining vendors use APPEND and why   
   should they change?   
   >>>>>   
   >>>>   
   >>>> $+! was even earlier. It predates the IBM PC XT.   
   >>>> (Osborne, CP/M)   
   >>>   
   >>> Even PLACE was new back then!   
   >>>   
   >>> String stacks often had $+ or equiv.  Somehow I never took to them.   
   >>> Not enough applications that warranted the effort?   
   >>   
   >> Let's face it - the string support was notoriously bad in Forth. People   
   >> openly complained about that.   
   >   
   > You must get rid of two ideas that are in the basic/lisp/c world.   
   >   
   > 1. You don't need dynamic strings. Just keep track of where you left them.   
   > [ If you really need them, don't do circular buffer or string stacks.   
   > Interface to the memory wordset (ALLOCATE c.s). ]   
   >   
   > 2. Zero ended strings is a stupid 60's c-cludge. Copying that into Forth is   
   > beyond ..  . They can't accomodate zero byte in strings, They cannot   
   > accomodate multiple byte characters.   
   >   
   > If you fetch a string, you have a "c-addr count". Forth can have 2 items   
   > on the stack you know.   
   >   
   > So In my CP/M day I get by with $! $@ $+! and $C+! .   
   > I made a program playing a text adventure game with that.   
      
   That may be all true - except:   
      
   1.. The variable keeps track where they are. It's a nifty little library   
   that frees you from buffer overflows and all other problems related to   
   "did I size 'em big enough?"   
   2. 4tH was created to work in close connection to C. So C strings it were.   
   3. Oh, no problem. I do *most* of the work with addr/count strings. But   
   sometimes you just have to store them.   
      
   BTW, 4tH has been doing C strings since its inception. It's not a big   
   problem - and 4tH has several safeguards that prevent you to go where no   
   man should have gone. That's the privilege of writing your own language.   
      
   The only problem is binary strings - because: even if they're delivered   
   correctly, you can't retrieve them if they contain a /0. True.   
      
   Most of the time binary strings are only required in a string constant -   
   and that's got accommodations. If not (which is rare) I have three   
   options - (a) faking a counted string (b) storing the addr/count in an   
   2VARIABLE or (c) holding on a addr/count string on the stack.   
      
   BTW, I've put the PARSE-ESC word to the test by compiling it unchanged   
   in Gforth:   
      
   : parse-esc   ( c-addr1 u1 c-addr2 -- c-addr3 u3 = Parse the escaped   
   character in string c-addr1 u1, store the result in string c-addr2 and   
   return the remaining string c-addr3 u3 ) compiling   
      over IF compiling   
        >r over c@ compiling   
        dup [char] x = IF drop chop r> est-add-2hex ;THEN compiling   
        dup [char] m = IF drop chop 13 c>s r@ +place 10 c>s r> +place ;THEN   
   *terminal*:398:43: warning: +place is obsolete   
   *terminal*:398:60: warning: +place is obsoletecompiling   
        dup [char] n = IF drop chop end-of-line count r> +place ;THEN   
   *terminal*:399:54: warning: +place is obsoletecompiling   
        dup [char] a [char] z 1+ within IF [char] a - chars est-table THEN   
   compiling   
        c>s r> +place chop   
   *terminal*:401:12: warning: +place is obsoletecompiling   
      ;THEN drop compiling   
     ok   
      
   (Yeah, I forgot a COUNT in the previous iteration - shoot me).   
      
   This is the test program:   
      
   create str 64 chars allot   
   : t2   
      0 str c!   
      s" a\a\b\e\f\q\r\t\v\q\n\m\xE0\\z"   
      begin   
        dup   
      while   
        str parse-esc .s   
      repeat   
      2drop str count cr dump cr .s   
      
      
   t2   
      
   Result:   
      
   (lots of uninteresting addresses)   
      
   7F6D8390EEC1: 07 5C 07 5C  08 5C 1B 5C - 0C 5C 22 5C  0D 5C 09 5C   
   .\.\.\.\.\"\.\.\   
   7F6D8390EED1: 0B 5C 22 5C  0A 5C 0D 0A - 5C E0 5C 5C  00   
   .\"\.\..\.\\.   
      
   <0>  ok   
      
   Versus 4tH:   
      
   (lots of uninteresting addresses)   
      
           0  1  2  3  4  5  6  7  8  9 10 11 12 13 14 15   
      
   1028  07 5C 07 5C 08 5C 1B 5C 0C 5C 22 5C 0D 5C 09 5C   
              \     \     \     \     \  "  \     \     \   
   1044  0B 5C 22 5C 0A 5C 0D 0A 5C E0 5C 5C 00 00 00 00   
              \  "  \     \        \  ~  \  \   
      
   Yeah - you can successfully abstract string formats..   
      
   Hans Bezemer   
      
   --- SoupGate-DOS v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)