Date: Sun, 27 Apr 2025 18:16:22 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: "The Best Programming Language for the End of the World"
Newsgroups: comp.lang.forth
References: <87bjtn2hct.fsf@gmail.com>
 <nnd$63e5382c$3fdcafbf@3f3b7214bd28514c>
 <nnd$6dfb43f9$1f045d73@735b02f46e71c0a3>
 <nnd$7772d25c$1baf7e22@e877e04d3a33b727>
 <nnd$7b77f132$00d02253@0069f67429321524>
Content-Language: en-US
From: Hans Bezemer <the.beez.speaks@gmail.com>
In-Reply-To: <nnd$7b77f132$00d02253@0069f67429321524>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Message-ID: <nnd$69b409f3$40dbcfe7@0069f67429321524>
Organization: KPN B.V.
Path: ...!news.misty.com!weretis.net!feeder9.news.weretis.net!usenet.blueworldhosting.com!diablo1.usenet.blueworldhosting.com!feed.abavia.com!abe005.abavia.com!abp004.abavia.com!news.kpn.nl!not-for-mail
Lines: 106
Injection-Date: Sun, 27 Apr 2025 18:16:22 +0200
Injection-Info: news.kpn.nl; mail-complaints-to="abuse@kpn.com"
Bytes: 5580

On 27-04-2025 16:30, albert@spenarnc.xs4all.nl wrote:
> In article <nnd$7772d25c$1baf7e22@e877e04d3a33b727>,
> Hans Bezemer  <the.beez.speaks@gmail.com> wrote:
>> On 27-04-2025 14:02, albert@spenarnc.xs4all.nl wrote:
>>> In article <nnd$63e5382c$3fdcafbf@3f3b7214bd28514c>,
>>> Hans Bezemer  <the.beez.speaks@gmail.com> wrote:
>>>> On 27-04-2025 08:21, dxf wrote:
>>>>> On 26/04/2025 9:07 pm, albert@spenarnc.xs4all.nl wrote:
>>>>>> In article <b73cd7a7ab393f51bfaa18a9171086732bcc0bdf@i2pn2.org>,
>>>>>> dxf  <dxforth@gmail.com> 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