On Saturday, October 7, 2023 at 3:54:59 PM UTC+2, Hans Bezemer wrote:
> I just reported the original Tom Zimmer source and ..
"Reported".. Meaning I did the port AGAIN. I didn't rat out the poor guy to some authority.
Just to make that clear.

Hans Bezemer

On 6/10/2023 10:36 pm, albert wrote:
> In article <2023Oct6.132456@mips.complang.tuwien.ac.at>,
> Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>> Hans Bezemer <the.beez.speaks@gmail.com> writes:
>>> On Thursday, October 5, 2023 at 8:47:24=E2=80=AFPM UTC+2, Doug Hoffman wrot=
>>> e:
>>>> Replace, e.,g., [ " WELCOME" ] with [ s" WELCOME" ]=20
>>>> and then it will compile and run on Gforth 0.7.3=20
>>> Oops, sorry - forgot that one!
>>>
>>> I ran it on Gforth 0.7.9_20230726.
>>
>> Note that in recent Gforth snapshots S" WELCOME" is equivalent to
>> "WELCOME", not " WELCOME".
>
> I urge everybody to add normal-looking strings like "WELCOME" with
> unrestricted life span to their Forths. We have a million fold
> progress in storage space since Forth began.

And still it would be hard to justify. Forth has managed without
these things for so long they'd now have the appearance of a novelty.
It's what I feel when I see 200x quoted characters.

In article <e111f0c6-ff4c-48ec-9955-d7c221a41624n@googlegroups.com>,
Hans Bezemer <the.beez.speaks@gmail.com> wrote:
<SNIP>
>> If language standards came with a user-satisfaction rating, I suspect Forth's wouldn't
>> do so well.
>I'd give Forth-79 a 7 out of 10, Forth-83 off the scale - minus infinity and ANS-Forth a 6.
>The main benefits of ANS are IMHO word sets and the abstraction of numeric
>datatypes (CELLS, CHARS, FLOATS). Ignoring COMUS words and leaving essential stuff
>like retrieving and storing strings completely open was a huge error. And some wordsets
>are just plain horrors (like LOCAL and FILE).

The LOCAL wordset with its reliance on control variables and a cooky
deviation from normal Forth syntax, there I agree.
However the FILE wordset? How can one do serious work in a programming
language to have at least a rudimentary file access?
Unix success is in no small part thanks to the OPEN READ/WRITE CLOSE
model and named files. You must at least replace them.

I deviate from ANSI inasfar not using suggested implementation routes:
WORD,FIND,COUNT for strings, (LOCAL) GET-ORDER SET-ORDER CS-ROLL
>IN are not present in the ciforth kernel.
The kernel of ciforth is much more elegant and concise, and those
other words can be added as needed, but there is hardly any
need to deviate from the standard. If I did there was a technical
reason for it, not simple an aversion.
An example are the obligatory throw codes. QUIT is the
read-interpret-ok loop. It is quite arbitrary to add a throw code
for that, and it boggles the mind what a reasonable catch would
be. The THROW codes usable to write portable code among Linux
and MS-W ? Good luck with that.
So I decided to use error/throw codes from the OS for OS-things
and differentiate between ciforth-errors that ANSI does not allow
me to differentiate. Linux and MS-W have different error codes
and I don't mess with it.

Bezemer

Groetjes Albert
--
Don't praise the day before the evening. One swallow doesn't make spring.
You must not say "hey" before you have crossed the bridge. Don't sell the
hide of the bear until you shot it. Better one bird in the hand than ten in
the air. First gain is a cat spinning. - the Wise from Antrim -

On Sunday, October 8, 2023 at 5:07:29 AM UTC+2, dxf wrote:
> > I urge everybody to add normal-looking strings like "WELCOME" with
> > unrestricted life span to their Forths. We have a million fold
> > progress in storage space since Forth began.
> And still it would be hard to justify. Forth has managed without
> these things for so long they'd now have the appearance of a novelty.
> It's what I feel when I see 200x quoted characters.
Neither do I. 4tH stores such strings in R/O memory - and only when
they are called, are they copied to a circular buffer - as if "I've been here
all the time, now use me like you want".
https://sourceforge.net/p/forth-4th/wiki/Temporary%20strings/

It rarely causes any problems. As a matter of fact, I tend to forget that's
how it works - so it's quite transparent I suppose.

In a way you can say they're stored permanently, though. S\" are only
available in the preprocessor - expanded at runtime. It's overhead, so
I tend not to use them.

There are other ways to compose a string with embedded special
characters - and 4tH also features S| Welcome| as an alternative.

Hans Bezemer

On 9/10/2023 4:07 am, Hans Bezemer wrote:
> On Sunday, October 8, 2023 at 5:07:29 AM UTC+2, dxf wrote:
>>> I urge everybody to add normal-looking strings like "WELCOME" with
>>> unrestricted life span to their Forths. We have a million fold
>>> progress in storage space since Forth began.
>> And still it would be hard to justify. Forth has managed without
>> these things for so long they'd now have the appearance of a novelty.
>> It's what I feel when I see 200x quoted characters.
> Neither do I. 4tH stores such strings in R/O memory - and only when
> they are called, are they copied to a circular buffer - as if "I've been here
> all the time, now use me like you want".
> https://sourceforge.net/p/forth-4th/wiki/Temporary%20strings/
>
> It rarely causes any problems. As a matter of fact, I tend to forget that's
> how it works - so it's quite transparent I suppose.
>
> In a way you can say they're stored permanently, though. S\" are only
> available in the preprocessor - expanded at runtime. It's overhead, so
> I tend not to use them.

Perhaps it's the type of apps I write but I haven't had much need
of persistent temporary strings. Should I need two there's PAD
and even the HOLD buffer. I don't do much interactive work.

> There are other ways to compose a string with embedded special
> characters - and 4tH also features S| Welcome| as an alternative.

Escape stuff in strings I couldn't avoid so I just built that into
.." S" etc. I know it's not ANS compatible. Got an email from a
user who seemed more interested in the fact I provided something.