From: the.beez.speaks@gmail.com   
      
   On 27-04-2025 16:30, albert@spenarnc.xs4all.nl wrote:   
   > In article ,   
   > Hans Bezemer   wrote:   
   >> 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.   
   >>>   
   >>> Groetjes Albert   
   >>>   
   >>>   
   >>>   
   >>>>   
   >>>> Hans Bezemer   
   >>   
   >>   
   >> -- 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.   
   >>   
   >> Well, the "club" has killed that one, so it bears no longer any   
   >> significance. FYI: I was not in favor of this proposition, it reeked   
   >> extremely Forth-83:   
   >>   
   >> "Since then, in 2016 the Forth-200x committee in favour of eliminating   
   >> ambiguous conditions has decided to require “1 CHARS = 1” thus making   
   >> systems that have other character sizes than on not compliant to   
   >> _future_ Forth-200x standards [2][3]. Requesting standard systems to   
   >> have byte size characters limit counted strings to the known maximal   
   >> length of 255 characters."   
   >   
   > No. That applies to a string stored in memory.   
   > A beneficial principle is to disambiguate the type of parameters   
   > passed around.   
   > So `WORD requiring a byte count in front of the characters in memory is   
   > a mistake. So in my core strings are exclusively passed as (addr length)   
   > and length can be 63 bit. So a I have `GET-FILE:   
   >   
   > (sc -- addr len) Get the content of file name sc  (string constant).   
   > Errors are thrown.   
   >   
   > Also in my core dictionary entries are identified as one address called   
   > "dea".   
   > No "name token", because it may not have a name filled in.   
   > Not "execution token", because the execution behaviour can be changed   
   > by changing the code field content.   
   > Not a "word" because what is a word without a name?   
   > [This  was triggered by the horror of n fields in transputer Forth and   
   > n*n conversions between these fields. (data field >>> forget field ...).   
   > Never looked back.   
   > Through jonesforth most Forth's created nowadays sport a uniform   
   > dea (CDFLN) , because jones borrowed this compelling idea from ciforth,   
   > and is hard to abandon, once it takes hold. ]   
      
   Gee. And me thinking PLACE and +PLACE were all about strings in memory.   
   My mistake. Of course it's all about "strings in memory". Since when has   
   Forth to do with strings on file? There are a million possible text file   
   formats..   
      
   If I wanna read an UTF-16 or UTF-32 from disk I could store the whole   
   shebang in the integer segment - and fake 64-bit characters. It'll work   
   fine. Sure, I gotta make some new library to process those files, but so   
   what?   
      
   And BTW, It's time to discard WORD. Horrible abomination. A relic from   
   the past.   
      
   Hans Bezemer   
      
   --- SoupGate-DOS v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)