Re: "The Best Programming Language for the End of the World"

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