It's Late and I'm Hitting a Wall

720 views
Skip to first unread message

Rick C

unread,
May 27, 2022, 1:20:57 AMMay 27
to
I have some old code that is writing to a S" string on a PC under Windows. It seems to work, but it appears to be a not so valid usage. Should I do this using a proper buffer?

I always worry about using PAD, but it seems ok in this case. The string is being handed to another word and is used right away. It is the prompt in a user control point in the program. "Hit any key for this and any other key for that", sort of thing.

I should just put it off until tomorrow, but I sleep better knowing a thing is done.

--

Rick C.

- Get 1,000 miles of free Supercharging
- Tesla referral code - https://ts.la/richard11209

NN

unread,
May 27, 2022, 4:21:15 AMMay 27
to
1) What does writing to a S" mean?
2) If it works why are you bothered by usage?
3) What's a proper buffer ?




Anton Ertl

unread,
May 27, 2022, 12:09:07 PMMay 27
to
Rick C <gnuarm.del...@gmail.com> writes:
>I have some old code that is writing to a S" string on a PC under Windows. It seems to work, but it appears to be a not so valid usage. Should I do this using a proper buffer?

If you want something portable and maintainable, yes. Otherwise, if
you know your Forth system and you know why the usage works, you can
leave it.

- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2021: https://euro.theforth.net/2021

Paul Rubin

unread,
May 27, 2022, 12:55:11 PMMay 27
to
NN <novembe...@gmail.com> writes:
> 2) If it works why are you bothered by usage?

If you try something and it works when you try it, that only means that
it worked the time you tried it. I.e. that it works at least some of
the time.

It is preferable to write code that always works. For that, you have to
know what it is actually doing, not just what it appears to do.

Rick C

unread,
May 27, 2022, 1:43:38 PMMay 27
to
S" Channel 0 audio test has ERRORS, Repeating test"
3DUP DROP 8 CHARS + SWAP '0' + C! UserPrompt

UserPrompt is a word that handles the prompt to the user and the response. This string is in RAM in a PC and appears to not be protected from writing, but I think this is not valid and may not work in all cases.

> 2) If it works why are you bothered by usage?

The same reason why I don't drive on bald tires. Yeah, they work ok until something else happens...


> 3) What's a proper buffer ?

If you don't know what a buffer is, then we don't need to continue the conversation. Are you being facetious?

--

Rick C.

+ Get 1,000 miles of free Supercharging
+ Tesla referral code - https://ts.la/richard11209

Rick C

unread,
May 27, 2022, 1:48:32 PMMay 27
to
I probably wrote the original code that way because manipulating such strings is a bit of a PITA. I only write in Forth once a year or two and forget so much. I can never recall all the details of string words. So I guess I'll go back to the books.

Speaking of which, I found some amazing web sites for HTML!

www.w3schools.com

This one is making that part of my life so much easier. I think they want to make it easy, to get you convinced you can learn it and they sell certifications (which I'm sure are much harder and many wouldn't try if they knew). Win-win!

--

Rick C.

-- Get 1,000 miles of free Supercharging
-- Tesla referral code - https://ts.la/richard11209

NN

unread,
May 27, 2022, 4:06:49 PMMay 27
to
If he knew it was not valid why ask the question. Fix it.
And if it was working why worry.

The answer to your line of thought is write a test. You are done.
If the test fails then there is a problem to fix. If it passes find something else.


NN

unread,
May 27, 2022, 4:12:32 PMMay 27
to
On Friday, 27 May 2022 at 18:43:38 UTC+1, gnuarm.del...@gmail.com wrote:
> On Friday, May 27, 2022 at 4:21:15 AM UTC-4, NN wrote:
> > On Friday, 27 May 2022 at 06:20:57 UTC+1, gnuarm.del...@gmail.com wrote:
> > > I have some old code that is writing to a S" string on a PC under Windows. It seems to work, but it appears to be a not so valid usage. Should I do this using a proper buffer?
> > >
> > > I always worry about using PAD, but it seems ok in this case. The string is being handed to another word and is used right away. It is the prompt in a user control point in the program. "Hit any key for this and any other key for that", sort of thing.
> > >
> > > I should just put it off until tomorrow, but I sleep better knowing a thing is done.
> > >
> > > --
> > >
> > > Rick C.
> > >
> > > - Get 1,000 miles of free Supercharging
> > > - Tesla referral code - https://ts.la/richard11209
> > 1) What does writing to a S" mean?
> S" Channel 0 audio test has ERRORS, Repeating test"
> 3DUP DROP 8 CHARS + SWAP '0' + C! UserPrompt
>
> UserPrompt is a word that handles the prompt to the user and the response. This string is in RAM in a PC and appears to not be protected from writing, but I think this is not valid and may not work in all cases.

Why do you believe its not valid and can you expand further as to under what conditions it may not work

> > 2) If it works why are you bothered by usage?
> The same reason why I don't drive on bald tires. Yeah, they work ok until something else happens...

Stick to forth unless you are trolling

> > 3) What's a proper buffer ?
> If you don't know what a buffer is, then we don't need to continue the conversation. Are you being facetious?

Its your terminology .
If you need to ask the answer is obviously NO !

Bernd Linsel

unread,
May 27, 2022, 4:53:25 PMMay 27
to
On 27.05.2022 10:21, NN wrote:
[...]
> 3) What's a proper buffer ?

Guess he means https://forth-standard.org/standard/core/BUFFERColon

Rick C

unread,
May 27, 2022, 4:58:42 PMMay 27
to
Thank you for your advice.

--

Rick C.

-+ Get 1,000 miles of free Supercharging
-+ Tesla referral code - https://ts.la/richard11209

dxforth

unread,
May 27, 2022, 11:30:31 PMMay 27
to
On 28/05/2022 03:48, Rick C wrote:
> On Friday, May 27, 2022 at 12:55:11 PM UTC-4, Paul Rubin wrote:
>> NN <novembe...@gmail.com> writes:
>> > 2) If it works why are you bothered by usage?
>> If you try something and it works when you try it, that only means that
>> it worked the time you tried it. I.e. that it works at least some of
>> the time.
>>
>> It is preferable to write code that always works. For that, you have to
>> know what it is actually doing, not just what it appears to do.
>
> I probably wrote the original code that way because manipulating such strings is
> a bit of a PITA.

Manipulating strings is so common that it's worth having the tools

\ Resident functions in DX-Forth
: (D.) ( d -- a u ) tuck dabs <# #s rot sign #> ;
: (.) ( n -- a u ) s>d (d.) ;
: +STRING ( a1 u1 a2 u2 -- a2 u1+u2 ) 2swap swap 2over + 2 pick move + ;
: >PAD ( a u -- a2 u ) pad 0 +string ;

: ChanErr$ ( chan# -- a u )
(.) s" Channel " >pad +string
s" audio test has ERRORS, Repeating test" 2swap +string ;

Rick C

unread,
May 28, 2022, 12:28:52 AMMay 28
to
Thank you. Not only do I not use Forth nearly enough to get proficient, I work alone, so don't have much interaction while I'm using it. This helps.

--

Rick C.

+- Get 1,000 miles of free Supercharging
+- Tesla referral code - https://ts.la/richard11209

S Jack

unread,
May 28, 2022, 10:06:21 AMMay 28
to
On Friday, May 27, 2022 at 12:20:57 AM UTC-5, gnuarm.del...@gmail.com wrote:
> I have some old code that is writing to a S" string on a PC under Windows. It seems to work, but it appears to be a not so valid usage. Should I do this using a proper buffer?
>

If you are over writing an existing string, you had better check that you
do not overflow the existing string's buffer. Buffer overflows are nasty
because their corruptions may not show up until much later leaving no clue
as to the problem.
For a string that needs to change use a string variable which has a maximum
size with which to test before writing into the string buffer.
--
me

Rick C

unread,
May 28, 2022, 3:54:22 PMMay 28
to
DXForth gave some useful example code that I might use at a later date. For now, I am simply replacing one character in the string and it seems to work. I need to prioritize my concerns and some other issues are causing more trouble.

--

Rick C.

++ Get 1,000 miles of free Supercharging
++ Tesla referral code - https://ts.la/richard11209

Hans Bezemer

unread,
Jun 7, 2022, 7:14:46 AMJun 7
to
On Saturday, May 28, 2022 at 9:54:22 PM UTC+2, gnuarm.del...@gmail.com wrote:
> I have some old code that is writing to a S" string on a PC under Windows.
> It seems to work, but it appears to be a not so valid usage. Should I do this
> using a proper buffer?

Technically, an implementer may do with S" whatever they want:

"Store the resulting string c-addr u at a temporary location. The
maximum length of the temporary buffer is implementation-dependent but shall
be no less than 80 characters. Subsequent uses of S" may overwrite the
temporary buffer. At least one such buffer shall be provided".

So - you may assume that whatever is there is both limited in time and
space. My suggestion would be: if you want to do anything fancy with it and want
it to run on as many platforms as possible, copy it ASAP to a buffer of your own.

That's what I suggest to the users of my own compiler anyway:
https://sourceforge.net/p/forth-4th/wiki/Temporary%20strings/

Hans Bezemer

none albert

unread,
Jun 7, 2022, 12:10:33 PMJun 7
to
In article <251f2cc0-c7a3-4e3b...@googlegroups.com>,
Hans Bezemer <the.bee...@gmail.com> wrote:
>On Saturday, May 28, 2022 at 9:54:22 PM UTC+2, gnuarm.del...@gmail.com wrote:
>> I have some old code that is writing to a S" string on a PC under Windows.
>> It seems to work, but it appears to be a not so valid usage. Should I do this
>> using a proper buffer?
>
>Technically, an implementer may do with S" whatever they want:
>
>"Store the resulting string c-addr u at a temporary location. The
>maximum length of the temporary buffer is implementation-dependent but shall
>be no less than 80 characters. Subsequent uses of S" may overwrite the
>temporary buffer. At least one such buffer shall be provided".

Actually, they don't. I store the content of S" in the dictionary not
in a temporary buffer. This is more or less illegal.
I have yet to come accross a program that relies on the fact that HERE
is not changed by S" .
I could fix it with e.g. (untested)
: S" &" PARSE ALLOCATE THROW DUP SIZE ;
but it is still illegal. ALLOCATEd items are not "temporary",
but at least the dictionary pointer is not affected.

>
>So - you may assume that whatever is there is both limited in time and
>space. My suggestion would be: if you want to do anything fancy with it and want
>it to run on as many platforms as possible, copy it ASAP to a buffer of your own.
>
>That's what I suggest to the users of my own compiler anyway:
>https://sourceforge.net/p/forth-4th/wiki/Temporary%20strings/

Or you can rely on real quoted strings (string denotations)
"we gaan naar Rome"
en trust that they are permanent as the number 7.

>
>Hans Bezemer

Groetjes Albert
--
"in our communism country Viet Nam, people are forced to be
alive and in the western country like US, people are free to
die from Covid 19 lol" duc ha
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

dxforth

unread,
Jun 7, 2022, 8:36:06 PMJun 7
to
On 8/06/2022 02:10, albert wrote:
> In article <251f2cc0-c7a3-4e3b...@googlegroups.com>,
> Hans Bezemer <the.bee...@gmail.com> wrote:
>>On Saturday, May 28, 2022 at 9:54:22 PM UTC+2, gnuarm.del...@gmail.com wrote:
>>> I have some old code that is writing to a S" string on a PC under Windows.
>>> It seems to work, but it appears to be a not so valid usage. Should I do this
>>> using a proper buffer?
>>
>>Technically, an implementer may do with S" whatever they want:
>>
>>"Store the resulting string c-addr u at a temporary location. The
>>maximum length of the temporary buffer is implementation-dependent but shall
>>be no less than 80 characters. Subsequent uses of S" may overwrite the
>>temporary buffer. At least one such buffer shall be provided".
>
> Actually, they don't. I store the content of S" in the dictionary not
> in a temporary buffer. This is more or less illegal.
> I have yet to come accross a program that relies on the fact that HERE
> is not changed by S" .

Is that a challenge? :)

Funny because after 40 years of Forth Inc using the same variable for
two [presumed] mutually exclusive functions, an ANS programmer came up
with a code snippet that broke it. Long story short, Forth Inc caved
in. God's in his heaven. All's right with the world once again!

Rick C

unread,
Jun 7, 2022, 11:31:10 PMJun 7
to
I can't find the text you are quoting. It's not in my copy of the Forth 200x Draft 18.1.

Instead it says,

3.3.3.4
Text-literal regions
The text-literal regions, specified by strings compiled with S", S\" and C" may be read-only.
A program shall not store into the text-literal regions created by S", S\" and C" nor into any read-only
system variable or read-only transient regions.

--

Rick C.

--- Get 1,000 miles of free Supercharging
--- Tesla referral code - https://ts.la/richard11209

minf...@arcor.de

unread,
Jun 8, 2022, 2:42:20 AMJun 8
to
Avoiding wordsmithing:
Since interpretation and compilation of S\" can become mixed (and appear within strings
for EVALUATE, even nested EVALUATEs or macros) I would not be happy to use HERE
for buffering.

Gerry Jackson

unread,
Jun 8, 2022, 7:23:01 AMJun 8
to
That's the sort of claptrap that only a dedicated ANS Forth hater intent on disinformation could come up with. I think the case you're misreprenting was a bug that I reported where a simplified version of the code is
<# 1234.
where the double number to be converted is not on the stack before <# is executed.
That has nothing to do with ANS Forth imposing extra restrictions, all standards back to FigForth have the stack diagram <# ( -- )
i.e. the double number is not required on the stack for <#

As for the nonsense about Forth Inc caving in - as the code above crashed SwiftForth why would a reputable Forth system supplier not fix a bug where valid Forth code crashed their system?

--
Gerry

Hans Bezemer

unread,
Jun 8, 2022, 8:32:04 AMJun 8
to
On Wednesday, June 8, 2022 at 5:31:10 AM UTC+2, gnuarm.del...@gmail.com wrote:
> I can't find the text you are quoting. It's not in my copy of the Forth 200x Draft 18.1.
>
> Instead it says,
>
> 3.3.3.4
> Text-literal regions
> The text-literal regions, specified by strings compiled with S", S\" and C" may be read-only.
> A program shall not store into the text-literal regions created by S", S\" and C" nor into any read-only
> system variable or read-only transient regions.

That may be because I quote the ANS-94 version. AFAIK every other incarnation of any Forth standard
is *not* ANS.

Hans Bezemer

Rick C

unread,
Jun 8, 2022, 8:56:26 AMJun 8
to
Sorry,, what Forth standards are there which are not ANS?

I've seen some people claim FIG was a standard, simply by example. Ok, I'm not going to argue that, even if I feel it is disingenuous.

Any others?

--

Rick C.

--+ Get 1,000 miles of free Supercharging
--+ Tesla referral code - https://ts.la/richard11209

Hans Bezemer

unread,
Jun 8, 2022, 9:27:11 AMJun 8
to
On Wednesday, June 8, 2022 at 2:56:26 PM UTC+2, gnuarm.del...@gmail.com wrote:
> I've seen some people claim FIG was a standard, simply by example.
It may have been a "de facto standard" if you want. But it wasn't backed by
any international standards body.

And "claims" by "some people" is not only "weasel speak", it's also quite possible
that some people DON'T consider it a standard - which evens it out and makes
the statement kind of superfluous.

> Ok, I'm not going to argue that, even if I feel it is disingenuous.
Since when is simply stating mere facts "disingenuous"?!

And it's an ambivalent statement as well. Is implied here that
the act of stating it is "disingenuous" or is the person stating it
"disingenuous". Be careful! You might hurt someones feelings.

Hans Bezemer

Rick C

unread,
Jun 8, 2022, 9:57:58 AMJun 8
to
Why do you quibble about totally unimportant points while ignoring the purpose of my post?

"Sorry,, what Forth standards are there which are not ANS?"

--

Rick C.

-+- Get 1,000 miles of free Supercharging
-+- Tesla referral code - https://ts.la/richard11209

Anton Ertl

unread,
Jun 8, 2022, 10:26:55 AMJun 8
to
Same wording in Forth-94 and in Forth-2012.

Text-literal regions are for 'strings compiled with S"', e.g.:

: foo s" bla" ;

These strings exist as long as the containing definition, and may be
in memory that you cannot overwrite (e.g., in flash memory). There is
also the interpretation semantics of S", for which the story is
different:

Forth-2012:

11.6.1.2165 S":
|Store the resulting string in a transient buffer c-addr u.
[...]
|See: [...] 11.3.4 Other transient regions

11.3.4 Other transient regions:
|The system provides transient buffers for S" and S\" strings. These
|buffers shall be no less than 80 characters in length, and there shall
|be at least two buffers. The system should be able to store two
|strings defined by sequential use of S" or S\". RAM-limited systems
|may have environmental restrictions on the number of buffers and their
|lifetimes.

So, basically, if you interpret

S" bla"

the resulting string will persist across the next interpretive S" or
S\", but the one after that may destroy the string. Forth-94 requires
only one buffer (and that's the text that the.bee...@gmail.com cited
without reference).

>Avoiding wordsmithing:

?

>Since interpretation and compilation of S\" can become mixed (and appear within strings
>for EVALUATE, even nested EVALUATEs or macros) I would not be happy to use HERE
>for buffering.

Interestingly, in Forth-94 "11.3.5 Other transient regions" refers to
"3.3.3.6 Other transient regions", which specifies that the named
transient regions become invalid (not in these words) by actions that
may change HERE, but in Forth-2012, "11.3.4 Other transient regions"
stands alone.
New standard: https://forth-standard.org/
EuroForth 2022: http://www.euroforth.org/ef22/cfp.html

Stephen Pelc

unread,
Jun 8, 2022, 10:57:32 AMJun 8
to
>
> Sorry,, what Forth standards are there which are not ANS?

Within the limits of a definition of "standard",
FIG, Forth-79, Forth-83, ANS-94, Forth-2012

Note that from Forth-2012 onwards, the latest document supersedes previous
documents.

Stephen
--
Stephen Pelc, ste...@vfxforth.com
MicroProcessor Engineering, Ltd. - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, +44 (0)78 0390 3612, +34 649 662 974
http://www.mpeforth.com - free VFX Forth downloads

dxforth

unread,
Jun 8, 2022, 11:45:25 AMJun 8
to
On 8/06/2022 21:22, Gerry Jackson wrote:
>
> As for the nonsense about Forth Inc caving in - as the code above crashed SwiftForth why would a reputable Forth system supplier not fix a bug where valid Forth code crashed their system?
>

Not a bug. You got them on an ANS technicality - namely there's nothing
in ANS which explicitly prevents a programmer from mixing number input
and output. That Forth Inc had no such need - indeed their systems were
designed on that basis - with apparently no complaints for over 40 years,
was irrelevant to you.

Gerry Jackson

unread,
Jun 8, 2022, 1:02:31 PMJun 8
to
On Wednesday, June 8, 2022 at 4:45:25 PM UTC+1, dxforth wrote:
> On 8/06/2022 21:22, Gerry Jackson wrote:
> >
> > As for the nonsense about Forth Inc caving in - as the code above crashed SwiftForth why would a reputable Forth system supplier not fix a bug where valid Forth code crashed their system?
> >
> Not a bug.

If some valid Forth code causes a standard Forth system to crash, that's a bug in my book and no amount of weasel wording will change my mind. When I develop a program for general use I like to make it portable and so test it on 5 or 6 Forth systems with a comprehensive test program. If all systems but one pass the test and one fails I investigate why and the cause was a more complex version of the code fragment under discussion. As it is standard code and several other systems work correctly the chances are that one system has a bug. The fact that Forth Inc accepted the fact without argument and fixed it in the next release indicates that they agree.

>You got them on an ANS technicality - namely there's nothing
> in ANS which explicitly prevents a programmer from mixing number input
> and output.

Why single out ANS? That is also a techicality for FigForth, Forth 79, Forth 83 and Forth 2012. Is it that you think ANS should have placed a restriction on mixing number input and output - if they had you would, no doubt have bitched about that.

> That Forth Inc had no such need - indeed their systems were
> designed on that basis

I suspect that using a single variable for two totally different purposes (bad programming practice) was a decision taken in the early days of Forth when saving a bit of memory was important on resource limited computers. As it is probably implemented by a bit of simple low level code when they moved to more sophisticated processors with a lot of memory they probably never reviewed that bit of code and so it lingered on.

> - with apparently no complaints for over 40 years,
> was irrelevant to you.

It wasn't irrelevant to me, it caused me work tracking down the problem. What's the time factor got to do with a bug, you might have a case if something meant a fundamental rework of part of a system but I don't think that's the case here. Adding a user variable and changing references to it doesn't sound complicated.

dxforth

unread,
Jun 8, 2022, 1:28:02 PMJun 8
to
On 8/06/2022 22:56, Rick C wrote:
> On Wednesday, June 8, 2022 at 8:32:04 AM UTC-4, the.bee...@gmail.com wrote:
>> On Wednesday, June 8, 2022 at 5:31:10 AM UTC+2, gnuarm.del...@gmail.com wrote:
>> > I can't find the text you are quoting. It's not in my copy of the Forth 200x Draft 18.1.

It was in Forth-94 (ANS) 11.6.1.2165 but has since been incorporated into 6.1.2165
Details of the "transient buffer" seem to have gone AWOL

There's a newer 'Draft'

http://www.forth200x.org/documents/forth19-1.pdf

not that it helps

Hans Bezemer

unread,
Jun 8, 2022, 1:37:55 PMJun 8
to
On Wednesday, June 8, 2022 at 4:57:32 PM UTC+2, Stephen Pelc wrote:
> >
> > Sorry,, what Forth standards are there which are not ANS?
> Within the limits of a definition of "standard",
> FIG, Forth-79, Forth-83, ANS-94, Forth-2012
It seems this one was accepted by ANSI: https://webstore.ansi.org/Standards/INCITS/ansix32151994

HB

dxforth

unread,
Jun 8, 2022, 1:40:11 PMJun 8
to
On 8/06/2022 23:57, Rick C wrote:
>
> "Sorry,, what Forth standards are there which are not ANS?"

Easier to ask which ones are.

"American National Standards Institute, Inc."

on the title page

Hans Bezemer

unread,
Jun 8, 2022, 1:47:33 PMJun 8
to
On Wednesday, June 8, 2022 at 3:57:58 PM UTC+2, gnuarm.del...@gmail.com wrote:
> Why do you quibble about totally unimportant points while ignoring the purpose of my post?
I don't. If you choose to use a pejorative term for me stating a simple fact
you'll be called out.

> "Sorry,, what Forth standards are there which are not ANS?"
I found only one: ANS-94 - technically: ANSI X3215-1994.

Hans Bezemer

Anton Ertl

unread,
Jun 8, 2022, 2:11:31 PMJun 8
to
Stephen Pelc <ste...@vfxforth.com> writes:
>>
>> Sorry,, what Forth standards are there which are not ANS?
>
>Within the limits of a definition of "standard",
> FIG, Forth-79, Forth-83, ANS-94, Forth-2012
>
>Note that from Forth-2012 onwards, the latest document supersedes previous
>documents.

My understanding is that Forth-2012 is the current standard (which is
also shown on forth-standard.org), and more recent documents are just
drafts for the next standard.

dxforth

unread,
Jun 8, 2022, 10:35:13 PMJun 8
to
On 9/06/2022 03:02, Gerry Jackson wrote:
> On Wednesday, June 8, 2022 at 4:45:25 PM UTC+1, dxforth wrote:
>> On 8/06/2022 21:22, Gerry Jackson wrote:
>> >
>> > As for the nonsense about Forth Inc caving in - as the code above crashed SwiftForth why would a reputable Forth system supplier not fix a bug where valid Forth code crashed their system?
>> >
>> Not a bug.
>
> If some valid Forth code causes a standard Forth system to crash, that's a bug in my book and no amount of weasel wording will change my mind. [...]

To me it looks like a failure of ANS to recognize 40 years of practice by a vendor.

dxforth

unread,
Jun 8, 2022, 11:46:36 PMJun 8
to
3.3.3.4 Text-literal regions
[...]
A system must provide at least two transient buffers for use with C", S" and S\"
strings. These buffers shall be no less than 80 characters in length. The system
should be able to store two strings defined by sequential use of these words.
RAM-limited systems may have environmental restrictions on the number of buffers
and their lifetimes.

IIRC you were using the compiling S" and writing to the string. Not portable
but permitted if you declare a dependency on the string being writeable.

ANS isn't for me as I never document my apps (only my forth - so vendors can't
accuse me of "undocumented unstable unsupported public domain Forth systems" :)

Rick C

unread,
Jun 9, 2022, 2:14:08 AMJun 9
to
On Wednesday, June 8, 2022 at 10:57:32 AM UTC-4, Stephen Pelc wrote:
> >
> > Sorry,, what Forth standards are there which are not ANS?
> Within the limits of a definition of "standard",
> FIG, Forth-79, Forth-83, ANS-94, Forth-2012
>
> Note that from Forth-2012 onwards, the latest document supersedes previous
> documents.

I am perhaps more confused now. "ANS-94" is not ANS?

--

Rick C.

-++ Get 1,000 miles of free Supercharging
-++ Tesla referral code - https://ts.la/richard11209

Rick C

unread,
Jun 9, 2022, 2:17:10 AMJun 9
to
Except that would not answer the question at all.

--

Rick C.

+-- Get 1,000 miles of free Supercharging
+-- Tesla referral code - https://ts.la/richard11209

Rick C

unread,
Jun 9, 2022, 2:21:28 AMJun 9
to
On Wednesday, June 8, 2022 at 1:47:33 PM UTC-4, the.bee...@gmail.com wrote:
> On Wednesday, June 8, 2022 at 3:57:58 PM UTC+2, gnuarm.del...@gmail.com wrote:
> > Why do you quibble about totally unimportant points while ignoring the purpose of my post?
> I don't. If you choose to use a pejorative term for me stating a simple fact
> you'll be called out.

Maybe this is a language problem, but I have no idea what you are talking about. I also don't care so much to have any discussion that involves being "called out". This sounds so grade school like.

--

Rick C.

+-+ Get 1,000 miles of free Supercharging
+-+ Tesla referral code - https://ts.la/richard11209

dxforth

unread,
Jun 9, 2022, 3:18:57 AMJun 9
to
On 9/06/2022 16:17, Rick C wrote:
> On Wednesday, June 8, 2022 at 1:40:11 PM UTC-4, dxforth wrote:
>> On 8/06/2022 23:57, Rick C wrote:
>> >
>> > "Sorry,, what Forth standards are there which are not ANS?"
>> Easier to ask which ones are.
>>
>> "American National Standards Institute, Inc."
>>
>> on the title page
>
> Except that would not answer the question at all.

'Google it, mate'

https://youtu.be/QxO8aF8SEYM

Rick C

unread,
Jun 9, 2022, 3:47:53 AMJun 9
to
Please take your stupidity elsewhere. Thank you.

--

Rick C.

++- Get 1,000 miles of free Supercharging
++- Tesla referral code - https://ts.la/richard11209

none albert

unread,
Jun 9, 2022, 4:29:30 AMJun 9
to
In article <t7rm8t$bcd$1...@gioia.aioe.org>, dxforth <dxf...@gmail.com> wrote:
>On 9/06/2022 03:02, Gerry Jackson wrote:
>> On Wednesday, June 8, 2022 at 4:45:25 PM UTC+1, dxforth wrote:
>>> On 8/06/2022 21:22, Gerry Jackson wrote:
>>> >
>>> > As for the nonsense about Forth Inc caving in - as the code above
>crashed SwiftForth why would a reputable Forth system supplier not fix a
>bug where valid Forth code crashed their system?
>>> >
>>> Not a bug.
>>
>> If some valid Forth code causes a standard Forth system to crash,
>that's a bug in my book and no amount of weasel wording will change my
>mind. [...]

Okay. Let's see. Is `` @ '' valid source code?
It certainly is. Can it crash a system? It certainly does!

>
>To me it looks like a failure of ANS to recognize 40 years of practice
>by a vendor.

If anything matters for a compiler that is stability.

There is a cost involved in fixing bugs. Any bug fix risks to
introduce other bugs.
There is a reason why ciforth went from 4.6.0 to 5.3.0 to 5.4.0
with years stability in between. And known bugs, be it a few.

none albert

unread,
Jun 9, 2022, 4:33:09 AMJun 9
to
In article <812f8214-42c3-4af0...@googlegroups.com>,
Rick C <gnuarm.del...@gmail.com> wrote:
>On Wednesday, June 8, 2022 at 1:40:11 PM UTC-4, dxforth wrote:
>> On 8/06/2022 23:57, Rick C wrote:
>> >
>> > "Sorry,, what Forth standards are there which are not ANS?"
>> Easier to ask which ones are.
>>
>> "American National Standards Institute, Inc."
>>
>> on the title page
>
>Except that would not answer the question at all.

I hate to say this, but has this been promoted to an ISO standard?
Why refer to an "American" standard, if it is International?

ciforth means "close to ISO" because I don't want to deter
Chinese users.

>
>Rick C.

Stephen Pelc

unread,
Jun 9, 2022, 6:03:08 AMJun 9
to
On 9 Jun 2022 at 08:14:06 CEST, "Rick C" <gnuarm.del...@gmail.com>
wrote:

> On Wednesday, June 8, 2022 at 10:57:32 AM UTC-4, Stephen Pelc wrote:
>>>
>>> Sorry,, what Forth standards are there which are not ANS?
>> Within the limits of a definition of "standard",
>> FIG, Forth-79, Forth-83, ANS-94, Forth-2012
>>
>> Note that from Forth-2012 onwards, the latest document supersedes previous
>> documents.
>
> I am perhaps more confused now. "ANS-94" is not ANS?

ANS-94 is the canonical ANS. Sorry.

Forth-2012 and its successors used ANS as a base.

Hans Bezemer

unread,
Jun 9, 2022, 6:55:13 AMJun 9
to
On Thursday, June 9, 2022 at 8:21:28 AM UTC+2, gnuarm.del...@gmail.com wrote:
> On Wednesday, June 8, 2022 at 1:47:33 PM UTC-4, the.bee...@gmail.com wrote:
> > On Wednesday, June 8, 2022 at 3:57:58 PM UTC+2, gnuarm.del...@gmail.com wrote:
> > > Why do you quibble about totally unimportant points while ignoring the purpose of my post?
> > I don't. If you choose to use a pejorative term for me stating a simple fact
> > you'll be called out.
> Maybe this is a language problem, but I have no idea what you are talking about.
I don't think it's a language problem:

Disingenuous:
https://dictionary.cambridge.org/dictionary/english/disingenuous
"slightly dishonest; not speaking the complete truth"

> I also don't care so much to have any discussion that involves being "called out".
> This sounds so grade school like.
Frankly, I couldn't care less about your opinions. If you don't even have the
facts at hand - or take the trouble to READ stuff to get the required information -
I don't think your opinion is something to care about.

Hans Bezemer

Rick C

unread,
Jun 9, 2022, 1:32:38 PMJun 9
to
On Thursday, June 9, 2022 at 4:33:09 AM UTC-4, none albert wrote:
> In article <812f8214-42c3-4af0...@googlegroups.com>,
> Rick C <gnuarm.del...@gmail.com> wrote:
> >On Wednesday, June 8, 2022 at 1:40:11 PM UTC-4, dxforth wrote:
> >> On 8/06/2022 23:57, Rick C wrote:
> >> >
> >> > "Sorry,, what Forth standards are there which are not ANS?"
> >> Easier to ask which ones are.
> >>
> >> "American National Standards Institute, Inc."
> >>
> >> on the title page
> >
> >Except that would not answer the question at all.
> I hate to say this, but has this been promoted to an ISO standard?
> Why refer to an "American" standard, if it is International?
>
> ciforth means "close to ISO" because I don't want to deter
> Chinese users.

Not sure what that means. Does being ISO compliant offend Chinese in some way?

--

Rick C.

+++ Get 1,000 miles of free Supercharging
+++ Tesla referral code - https://ts.la/richard11209

Gerry Jackson

unread,
Jun 9, 2022, 3:20:20 PMJun 9
to
On 09/06/2022 09:29, albert wrote:
> In article <t7rm8t$bcd$1...@gioia.aioe.org>, dxforth <dxf...@gmail.com> wrote:
>> On 9/06/2022 03:02, Gerry Jackson wrote:
>>> On Wednesday, June 8, 2022 at 4:45:25 PM UTC+1, dxforth wrote:
>>>> On 8/06/2022 21:22, Gerry Jackson wrote:
>>>>>
>>>>> As for the nonsense about Forth Inc caving in - as the code above
>> crashed SwiftForth why would a reputable Forth system supplier not fix a
>> bug where valid Forth code crashed their system?
>>>>>
>>>> Not a bug.
>>>
>>> If some valid Forth code causes a standard Forth system to crash,
>> that's a bug in my book and no amount of weasel wording will change my
>> mind. [...]
>
> Okay. Let's see. Is `` @ '' valid source code?
> It certainly is. Can it crash a system? It certainly does!

That's a different case. If an application or user feeds an invalid
address to @ that is a program error not a system bug.

>
>>
>> To me it looks like a failure of ANS to recognize 40 years of practice
>> by a vendor.

A feature provided by a single vendor is not common practice.

>
> If anything matters for a compiler that is stability.

I'd have thought being correct trumps buggy stability.

>
> There is a cost involved in fixing bugs.

Well who'd have thought it

> Any bug fix risks to introduce other bugs.

The risk can be greatly reduced by having a comprehensive test program

> There is a reason why ciforth went from 4.6.0 to 5.3.0 to 5.4.0
> with years stability in between. And known bugs, be it a few.

Is the reason idleness? IF the bugs had impacted on you I bet you'd have
fixed them immediately.

--
Gerry

dxforth

unread,
Jun 9, 2022, 5:27:44 PMJun 9
to
On 10/06/2022 05:20, Gerry Jackson wrote:
> On 09/06/2022 09:29, albert wrote:
>> In article <t7rm8t$bcd$1...@gioia.aioe.org>, dxforth <dxf...@gmail.com> wrote:
>>> On 9/06/2022 03:02, Gerry Jackson wrote:
>>>> On Wednesday, June 8, 2022 at 4:45:25 PM UTC+1, dxforth wrote:
>>>>> On 8/06/2022 21:22, Gerry Jackson wrote:
>>>>>>
>>>>>> As for the nonsense about Forth Inc caving in - as the code above
>>> crashed SwiftForth why would a reputable Forth system supplier not fix a
>>> bug where valid Forth code crashed their system?
>>>>>>
>>>>> Not a bug.
>>>>
>>>> If some valid Forth code causes a standard Forth system to crash,
>>> that's a bug in my book and no amount of weasel wording will change my
>>> mind. [...]
>>
>> Okay. Let's see. Is `` @ '' valid source code?
>> It certainly is. Can it crash a system? It certainly does!
>
> That's a different case. If an application or user feeds an invalid
> address to @ that is a program error not a system bug.

You're saying circumstances matter.

If you have two systems and they have complied with all the things
the Standard has instructed, then they are Standard Systems. Now
if code is introduced and they behave differently then what you
have is non-portable code.

Forth Inc's system was already Standard (if not, tell us where).
In making the change they merely made SwiftForth compatible with
your system. They could just as easily have said 'No - our system
is compliant, what we have works for us'.

dxforth

unread,
Jun 9, 2022, 9:21:54 PMJun 9
to
On 9/06/2022 17:47, Rick C wrote:
> On Thursday, June 9, 2022 at 3:18:57 AM UTC-4, dxforth wrote:
>> On 9/06/2022 16:17, Rick C wrote:
>> > On Wednesday, June 8, 2022 at 1:40:11 PM UTC-4, dxforth wrote:
>> >> On 8/06/2022 23:57, Rick C wrote:
>> >> >
>> >> > "Sorry,, what Forth standards are there which are not ANS?"
>> >> Easier to ask which ones are.
>> >>
>> >> "American National Standards Institute, Inc."
>> >>
>> >> on the title page
>> >
>> > Except that would not answer the question at all.
>> 'Google it, mate'
>>
>> https://youtu.be/QxO8aF8SEYM
>
> Please take your stupidity elsewhere. Thank you.

https://www.google.com/search?q=forth+standards

Rick C

unread,
Jun 9, 2022, 9:52:32 PMJun 9
to
On Thursday, June 9, 2022 at 1:32:38 PM UTC-4, Rick C wrote:
> On Thursday, June 9, 2022 at 4:33:09 AM UTC-4, none albert wrote:
> > In article <812f8214-42c3-4af0...@googlegroups.com>,
> > Rick C <gnuarm.del...@gmail.com> wrote:
> > >On Wednesday, June 8, 2022 at 1:40:11 PM UTC-4, dxforth wrote:
> > >> On 8/06/2022 23:57, Rick C wrote:
> > >> >
> > >> > "Sorry,, what Forth standards are there which are not ANS?"
> > >> Easier to ask which ones are.
> > >>
> > >> "American National Standards Institute, Inc."
> > >>
> > >> on the title page
> > >
> > >Except that would not answer the question at all.
> > I hate to say this, but has this been promoted to an ISO standard?
> > Why refer to an "American" standard, if it is International?
> >
> > ciforth means "close to ISO" because I don't want to deter
> > Chinese users.
> Not sure what that means. Does being ISO compliant offend Chinese in some way?

Oh, sorry, I understand. ANS is US and ISO is international. I can see where something only ANS compliant might be an issue for the Chinese. But there is no ISO Forth standard, no? So you claim of being "close to ISO" is "marketing" or "political"?

Sorry that I'm not really up to speed on this. I typically use Forth once in a year or two and often forget a great number of details. I've taken to adding notes to the standard documents to help me remember things more easily. I need to add my notes to the Draft 19.1 document. Sometimes I feel like the lead character in "Memento".

--

Rick C.

---- Get 1,000 miles of free Supercharging
---- Tesla referral code - https://ts.la/richard11209

Bernd Linsel

unread,
Jun 10, 2022, 4:14:57 AMJun 10
to
On 10.06.2022 03:52, Rick C wrote:
> Oh, sorry, I understand. ANS is US and ISO is international. I can see where something only ANS compliant might be an issue for the Chinese. But there is no ISO Forth standard, no? So you claim of being "close to ISO" is "marketing" or "political"?

https://www.iso.org/standard/26479.html

none albert

unread,
Jun 10, 2022, 4:49:27 AMJun 10
to
In article <66d40070-80f7-469a...@googlegroups.com>,
Rick C <gnuarm.del...@gmail.com> wrote:
>On Thursday, June 9, 2022 at 4:33:09 AM UTC-4, none albert wrote:
>> In article <812f8214-42c3-4af0...@googlegroups.com>,
>> Rick C <gnuarm.del...@gmail.com> wrote:
>> >On Wednesday, June 8, 2022 at 1:40:11 PM UTC-4, dxforth wrote:
>> >> On 8/06/2022 23:57, Rick C wrote:
>> >> >
>> >> > "Sorry,, what Forth standards are there which are not ANS?"
>> >> Easier to ask which ones are.
>> >>
>> >> "American National Standards Institute, Inc."
>> >>
>> >> on the title page
>> >
>> >Except that would not answer the question at all.
>> I hate to say this, but has this been promoted to an ISO standard?
>> Why refer to an "American" standard, if it is International?
>>
>> ciforth means "close to ISO" because I don't want to deter
>> Chinese users.
>
>Not sure what that means. Does being ISO compliant offend Chinese in
>some way?

American Standard Compliant could. I forget the smiley.
I'm chauvinist here. I prefer to replace standards set by USA
to international standards.

>
>--

none albert

unread,
Jun 10, 2022, 4:58:15 AMJun 10
to
In article <nnd$7b472a72$7adcbc4d@608fa32a2475eeb4>,
none) (albert <albert@cherry.> wrote:
>In article <66d40070-80f7-469a...@googlegroups.com>,
>Rick C <gnuarm.del...@gmail.com> wrote:
>>On Thursday, June 9, 2022 at 4:33:09 AM UTC-4, none albert wrote:
>>> In article <812f8214-42c3-4af0...@googlegroups.com>,
>>> Rick C <gnuarm.del...@gmail.com> wrote:
>>> >On Wednesday, June 8, 2022 at 1:40:11 PM UTC-4, dxforth wrote:
>>> >> On 8/06/2022 23:57, Rick C wrote:
>>> >> >
>>> >> > "Sorry,, what Forth standards are there which are not ANS?"
>>> >> Easier to ask which ones are.
>>> >>
>>> >> "American National Standards Institute, Inc."
>>> >>
>>> >> on the title page
>>> >
>>> >Except that would not answer the question at all.
>>> I hate to say this, but has this been promoted to an ISO standard?
>>> Why refer to an "American" standard, if it is International?
>>>
>>> ciforth means "close to ISO" because I don't want to deter
>>> Chinese users.
>>
>>Not sure what that means. Does being ISO compliant offend Chinese in
>>some way?
>
>American Standard Compliant could. I forget the smiley.
>I'm chauvinist here. I prefer to replace standards set by USA
>to international standards.

In particular
https://www.iso.org/standard/26479.html

"ISO/IEC 15145:1997
Information technology - Programming languages - Forth "

(...confirmed in 2021, ... current ..)

dxforth

unread,
Jun 10, 2022, 6:18:01 AMJun 10
to
"THIS STANDARD WAS LAST REVIEWED AND CONFIRMED IN 2021. THEREFORE THIS
VERSION REMAINS CURRENT."

Raises more questions. Do standards ever die? :)

none albert

unread,
Jun 10, 2022, 7:01:46 AMJun 10
to
Great effort is expended to keep the standard current and up to date.
See the work of Anton Ertl c.s.

dxforth

unread,
Jun 10, 2022, 7:50:44 AMJun 10
to
On 10/06/2022 21:01, albert wrote:
> In article <t7v5om$hf4$1...@gioia.aioe.org>, dxforth <dxf...@gmail.com> wrote:
>>On 10/06/2022 18:14, Bernd Linsel wrote:
>>> On 10.06.2022 03:52, Rick C wrote:
>>>> Oh, sorry, I understand. ANS is US and ISO is international. I can see where something only ANS compliant might be an issue for the Chinese. But there
>>is no ISO Forth standard, no? So you claim of being "close to ISO" is "marketing" or "political"?
>>>
>>> https://www.iso.org/standard/26479.html
>>>
>>
>>"THIS STANDARD WAS LAST REVIEWED AND CONFIRMED IN 2021. THEREFORE THIS
>> VERSION REMAINS CURRENT."
>>
>>Raises more questions. Do standards ever die? :)
>
> Great effort is expended to keep the standard current and up to date.
> See the work of Anton Ertl c.s.

The ANSI/ISO one referenced above?

Anton Ertl

unread,
Jun 10, 2022, 11:11:09 AMJun 10
to
dxforth <dxf...@gmail.com> writes:
>On 10/06/2022 21:01, albert wrote:
>> In article <t7v5om$hf4$1...@gioia.aioe.org>, dxforth <dxf...@gmail.com> wrote:
>>>Raises more questions. Do standards ever die? :)

They get superseded by newer standards, and some are considered
retired.

>> Great effort is expended to keep the standard current and up to date.
>> See the work of Anton Ertl c.s.
>
>The ANSI/ISO one referenced above?

The Forth 200x committee has not submitted a document to ANSI or ISO,
so I expect that ISO Forth is still Forth-94.

Rick C

unread,
Jun 10, 2022, 4:31:01 PMJun 10
to
It's not very often that a standard has separate versions ANS and ISO for something that is truly world wide. Can someone explain what is going on? Is the standard created under ANS and then also listed with ISO?

--

Rick C.

---+ Get 1,000 miles of free Supercharging
---+ Tesla referral code - https://ts.la/richard11209

dxforth

unread,
Jun 10, 2022, 9:20:32 PMJun 10
to
On 11/06/2022 06:30, Rick C wrote:
> On Friday, June 10, 2022 at 4:14:57 AM UTC-4, Bernd Linsel wrote:
>> On 10.06.2022 03:52, Rick C wrote:
>> > Oh, sorry, I understand. ANS is US and ISO is international. I can see where something only ANS compliant might be an issue for the Chinese. But there is no ISO Forth standard, no? So you claim of being "close to ISO" is "marketing" or "political"?
>> https://www.iso.org/standard/26479.html
>
> It's not very often that a standard has separate versions ANS and ISO for something that is truly world wide. Can someone explain what is going on? Is the standard created under ANS and then also listed with ISO?
>

Forth-94 made its appearance under the ISO imprimatur in 1996 some
two years after ANSI. How and by whom is as much a mystery to me
as who reviewed and approved it in 2021. According to ISO, reviews
are conducted each 5 years with the involvement of stakeholders.

Rick C

unread,
Jun 11, 2022, 1:37:48 AMJun 11
to
But why? If there's an ISO standard and an ANS standard, are they the same standard, kept in sync? Why not just have one?

--

Rick C.

--+- Get 1,000 miles of free Supercharging
--+- Tesla referral code - https://ts.la/richard11209

Anton Ertl

unread,
Jun 11, 2022, 2:52:29 AMJun 11
to
Rick C <gnuarm.del...@gmail.com> writes:
>If there's an ISO standard and an ANS standard, are they the same standard

Apart from the title page and such, they are the same in this case,
and that's how it should be and AFAIK usually is the case.

> kept in sync?

That's an interesting question. C89/C90 was developed under the ANSI
auspices ("ANSI C"), then fast-tracked as ISO standard ("ISO C"), like
ANS Forth. AFAIK they then continued on directly under ISO auspices,
and no longer under ANSI. But since ANSI is a member of ISO, any ISO
standard is also valid in the USA.

> Why not just have one?

If a nationally developed standard is elevated to an international
standard, as in the case of C and Forth, this by necessity means that
that standard is both.

dxforth

unread,
Jun 11, 2022, 5:19:31 AMJun 11
to
On 11/06/2022 16:37, Anton Ertl wrote:
> Rick C <gnuarm.del...@gmail.com> writes:
>>If there's an ISO standard and an ANS standard, are they the same standard
>
> Apart from the title page and such, they are the same in this case,
> and that's how it should be and AFAIK usually is the case.
>
>> kept in sync?
>
> That's an interesting question. C89/C90 was developed under the ANSI
> auspices ("ANSI C"), then fast-tracked as ISO standard ("ISO C"), like
> ANS Forth. AFAIK they then continued on directly under ISO auspices,
> and no longer under ANSI. But since ANSI is a member of ISO, any ISO
> standard is also valid in the USA.
>
>> Why not just have one?
>
> If a nationally developed standard is elevated to an international
> standard, as in the case of C and Forth, this by necessity means that
> that standard is both.

I read ISO has a proviso the standard must be in use in at least 5
countries else it can't be considered 'international'. Presumably
that's checked in the application/review. That makes ISO a standard
of the world - not for the world.

Rick C

unread,
Jun 11, 2022, 9:06:53 AMJun 11
to
On Saturday, June 11, 2022 at 2:52:29 AM UTC-4, Anton Ertl wrote:
> Rick C <gnuarm.del...@gmail.com> writes:
> >If there's an ISO standard and an ANS standard, are they the same standard
> Apart from the title page and such, they are the same in this case,
> and that's how it should be and AFAIK usually is the case.
>
> > kept in sync?
>
> That's an interesting question. C89/C90 was developed under the ANSI
> auspices ("ANSI C"), then fast-tracked as ISO standard ("ISO C"), like
> ANS Forth. AFAIK they then continued on directly under ISO auspices,
> and no longer under ANSI. But since ANSI is a member of ISO, any ISO
> standard is also valid in the USA.
> > Why not just have one?
> If a nationally developed standard is elevated to an international
> standard, as in the case of C and Forth, this by necessity means that
> that standard is both.

Sorry, maybe that's not the question. Why continue to develop the standard under ANS? Why not discontinue the ANS standard and only develop the ISO standard. Even if it is minimal effort to support both, it is extra work and a bit confusing. I recall when RS-232 was added to a world wide standard group. I believe it is no longer updated as the RS-232 standard.

Is there actually some advantage of having the ANS Forth standard in addition to the ISO Forth standard?

--

Rick C.

--++ Get 1,000 miles of free Supercharging
--++ Tesla referral code - https://ts.la/richard11209