Thought people in this group might be interested in this article on
Wired:
"Once the grid goes down, an old programming language called
Forth—and a new operating system called Collapse OS—may be our only salvation."
-- https://www.wired.com/story/forth-collapse-os-apocalypse-programming-language/
Alexis.No Wired subscription? Here's what you need:
No Wired subscription?
Martin Nicholas <reply-2025@mgn.org.uk> writes:
No Wired subscription?
i don't have a Wired subscription, and am able to access the full
article; is this not the case for you?
(My general policy is to not link to articles whose full version is
behind a paywall, with some exceptions where e.g. there's a
non-paywalled abstract which itself provides useful information.)
Alexis.
Thought people in this group might be interested in this article on
Wired:
"Once the grid goes down, an old programming language called Forth—and a new operating system called Collapse OS—may be our only salvation."
-- https://www.wired.com/story/forth-collapse-os-apocalypse-programming-language/
Alexis.
Writing a gopher, irc
and some small usenet client would be a breeze.
Writing a gopher, irc
and some small usenet client would be a breeze.
That should be the least of our worries when the world ends?
You (I) get one free article per month. After that I get the first few
lines and a prompt to subscribe. The fingerprinting is difficult to
defeat - I gave up.
On Fri, 28 Mar 2025 10:21:58 +1100
Alexis <flexibeast@gmail.com> wrote:
Martin Nicholas <reply-2025@mgn.org.uk> writes:
No Wired subscription?
i don't have a Wired subscription, and am able to access the full
article; is this not the case for you?
(My general policy is to not link to articles whose full version is
behind a paywall, with some exceptions where e.g. there's a
non-paywalled abstract which itself provides useful information.)
Alexis.
You (I) get one free article per month. After that I get the first few
lines and a prompt to subscribe. The fingerprinting is difficult to
defeat - I gave up.
Writing a gopher, irc
and some small usenet client would be a breeze.
That should be the least of our worries when the world ends?
-marcel
"Once the grid goes down, an old programming language called Forth?and a
new operating system called Collapse OS?may be our only salvation."
On 2025-03-29, mhx <mhx@iae.nl> wrote:
Writing a gopher, irc
and some small usenet client would be a breeze.
That should be the least of our worries when the world ends?
-marcel
More than 'end', Dusk OS looks great for 2nd/3rd world machines
with very few requirements. You might find surprised that Lagrange
and protocols like Gopher and Gemini among https://telae.net
are used in some part of South America.
More than 'the end of the world', think about 'non reliable
sources of power', shitty internet connections and so on.
DuskOS with TCP/IP, gopher/irc and maybe some basic soundcard
support would be great for low end i386 machines.
Writing a gopher, irc
and some small usenet client would be a breeze.
That should be the least of our worries when the world ends?
-marcel
Alexis <flexibeast@gmail.com> wrote:
"Once the grid goes down, an old programming language called Forth?and a
new operating system called Collapse OS?may be our only salvation."
_A Boy and His Dog_
Savaging old computer parts may work for awhile if one can avoid
the sea people, zombies and morlocks.
Thought people in this group might be interested in this article on
Wired:
"Once the grid goes down, an old programming language called Forth—and a new operating system called Collapse OS—may be our only salvation."
-- https://www.wired.com/story/forth-collapse-os-apocalypse-programming-language/
...
"I've looked at a lot of Forth code, and it's almost uniformly doc-free." That's an attitude problem - not a language problem.
"The average Forth program becomes much more quickly a mess of cryptic definitions only the original programmer understands." Again, a lack of documentation is not a problem of the language.
But after ten, twenty years I still find most of my programs are still perfectly maintainable - contrary to what most notorious Forth haters claim.
On 27-03-2025 06:05, Alexis wrote:This is debatable. C has left the bulk of functionality to procedures
Thought people in this group might be interested in this article on
Wired:
"Once the grid goes down, an old programming language called Forth—and a >> new operating system called Collapse OS—may be our only salvation."
-- https://www.wired.com/story/forth-collapse-os-apocalypse-programming-language/
As always, it's interesting which impression Forth leaves to a newbie -
even if it's completely negative. Think of >https://www.embedded.com/i-hate-forth/
"Forth is also a write-only language. The language is simple with few >keywords." Which is not true. C has a few dozen keywords. 4tH has a few >hundred.
"I've looked at a lot of Forth code, and it's almost uniformlyI agree. Most programmers agree that ( -- ) is sufficient documentation.
doc-free." That's an attitude problem - not a language problem.
"The average Forth program becomes much more quickly a mess of cryptic >definitions only the original programmer understands." Again, a lack of >documentation is not a problem of the language.Sadly this is true more often than not.
But after ten, twenty years I still find most of my programs are still >perfectly maintainable - contrary to what most notorious Forth haters
claim. For me, it works. That doesn't mean that other opinions are
invalid - it just means I'm not them.
Hans Bezemer
In article <nnd$4e8dcfed$6eb3f489@d30798298ac0a139>,
Hans Bezemer <the.beez.speaks@gmail.com> wrote:
On 27-03-2025 06:05, Alexis wrote:...
"I've looked at a lot of Forth code, and it's almost uniformlyI agree. Most programmers agree that ( -- ) is sufficient documentation.
doc-free." That's an attitude problem - not a language problem.
My advice is : precede each word with a specification that allows
the use of this word. The ideal is that the definition itself is
in fact the documentation of the definition. This is Chuck Moore's
pipe dream.
: FOPEN ( a n fam -- ) open-file s" open" ferr cf ! ;
On 4/04/2025 10:36 pm, albert@spenarnc.xs4all.nl wrote:
In article <nnd$4e8dcfed$6eb3f489@d30798298ac0a139>,
Hans Bezemer <the.beez.speaks@gmail.com> wrote:
On 27-03-2025 06:05, Alexis wrote:...
"I've looked at a lot of Forth code, and it's almost uniformlyI agree. Most programmers agree that ( -- ) is sufficient documentation.
doc-free." That's an attitude problem - not a language problem.
My advice is : precede each word with a specification that allows
the use of this word. The ideal is that the definition itself is
in fact the documentation of the definition. This is Chuck Moore's
pipe dream.
I'm not so sure. 10 definitions and 2 comments. Does it need more?
\ Encountered file error, display msg, filename then quit
: FERR ( ? ior a u -- ? ) rot 0= if 2drop end
cr ." File error: " type ." - " @fname type abort ;
: FOPEN ( a n fam -- ) open-file s" open" ferr cf ! ;
: FCREAT ( a n fam -- ) create-file s" create" ferr cf ! ;
: FREAD ( a n -- n' ) cf @ read-file s" read" ferr ;
: FWRITE ( a n -- ) cf @ write-file s" write" ferr ;
: FSEEK ( ud -- ) cf @ reposition-file s" position" ferr ;
: FCLOSE ( -- ) cf @ close-file s" close" ferr ;
\ Install terminal data at offs to target at adr
: SET.S ( a ofs -- ) dbuf + count rot >target place ;
: SET.W ( a ofs -- ) dbuf + @ swap >target ! ;
: SET.B ( a ofs -- ) dbuf + c@ swap >target c! ;
In article <cf9dc70297223ad4a39ba1a4ba2c072c8737e306@i2pn2.org>,[..]
dxf <dxforth@gmail.com> wrote:
On 4/04/2025 10:36 pm, albert@spenarnc.xs4all.nl wrote:
In article <nnd$4e8dcfed$6eb3f489@d30798298ac0a139>,
Hans Bezemer <the.beez.speaks@gmail.com> wrote:
On 27-03-2025 06:05, Alexis wrote:
I'm not so sure. 10 definitions and 2 comments. Does it need more?
\ Encountered file error, display msg, filename then quit
: FERR ( ? ior a u -- ? ) rot 0= if 2drop end
cr ." File error: " type ." - " @fname type abort ;
: FOPEN ( a n fam -- ) open-file s" open" ferr cf ! ;
: FCREAT ( a n fam -- ) create-file s" create" ferr cf ! ;
: FREAD ( a n -- n' ) cf @ read-file s" read" ferr ;
: FWRITE ( a n -- ) cf @ write-file s" write" ferr ;
: FSEEK ( ud -- ) cf @ reposition-file s" position" ferr ;
: FCLOSE ( -- ) cf @ close-file s" close" ferr ;
In article <slrnvuik3u.miq.anthk@openbsd.home>,
anthk <anthk@openbsd.home> wrote:
On 2025-03-29, mhx <mhx@iae.nl> wrote:
Writing a gopher, irc
and some small usenet client would be a breeze.
That should be the least of our worries when the world ends?
-marcel
More than 'end', Dusk OS looks great for 2nd/3rd world machines
with very few requirements. You might find surprised that Lagrange
and protocols like Gopher and Gemini among https://telae.net
are used in some part of South America.
More than 'the end of the world', think about 'non reliable
sources of power', shitty internet connections and so on.
DuskOS with TCP/IP, gopher/irc and maybe some basic soundcard
support would be great for low end i386 machines.
The third world is developing faster than the first world because
of the second world.
Because of the Belt and Road initiative and investments from China but
mostly of the incompetence of Musk and Trump, USA becomes the third
world, and the other worlds move one place up.
Don't expect i386 relevant in other places than the USA.
arm and riscv rule!
Huawei is deploying 6G and once finished starlink can't compete,
because they need ground stations everywhere.
Robot factories can crank out one smart phone per second, so the now
poor countries can afford them. Read up on 'xiao mi'.
Groetjes Albert
On Sat, 5 Apr 2025 6:40:15 +0000, albert@spenarnc.xs4all.nl wrote:
In article <cf9dc70297223ad4a39ba1a4ba2c072c8737e306@i2pn2.org>,[..]
dxf <dxforth@gmail.com> wrote:
On 4/04/2025 10:36 pm, albert@spenarnc.xs4all.nl wrote:
In article <nnd$4e8dcfed$6eb3f489@d30798298ac0a139>,
Hans Bezemer <the.beez.speaks@gmail.com> wrote:
On 27-03-2025 06:05, Alexis wrote:
I'm not so sure. 10 definitions and 2 comments. Does it need more?
\ Encountered file error, display msg, filename then quit
: FERR ( ? ior a u -- ? ) rot 0= if 2drop end
cr ." File error: " type ." - " @fname type abort ;
: FOPEN ( a n fam -- ) open-file s" open" ferr cf ! ;
: FCREAT ( a n fam -- ) create-file s" create" ferr cf ! ;
: FREAD ( a n -- n' ) cf @ read-file s" read" ferr ;
: FWRITE ( a n -- ) cf @ write-file s" write" ferr ;
: FSEEK ( ud -- ) cf @ reposition-file s" position" ferr ;
: FCLOSE ( -- ) cf @ close-file s" close" ferr ;
Well... What are @fname and cf ? What message do I get when I
open file1, then file2, start processing file1, and encounter a
FSEEK error? Are both file2 and file1 closed?
When doing a load of a deeply nested file, what are the
diagnostics when there is an error in a definition? Are errors
in definitions mentioning the file name / line numbers when the
definition executes, not only when it is being compiled? Can I
use FSEEK in case a few files are open? Which file closes when
FCLOSE is executed in case of a nested load?
Clearly some documentation is missing on the WHAT, but also
with respect to the HOW : is this interface doing what I
expect from it and/or can I adapt it to my demands.
dxf <dxforth@gmail.com> writes:
: FOPEN ( a n fam -- ) open-file s" open" ferr cf ! ;
I'm used to functions like this returning file handles instead of
storing into a global var, so you can have more than one file active at
the same time.
...
Clearly some documentation is missing on the WHAT, but also
with respect to the HOW : is this interface doing what I
expect from it and/or can I adapt it to my demands.
On 5/04/2025 6:12 pm, mhx wrote:[..]
On the topic of documentation Forth Standard (the document to which
everyone looks) hasn't clarified aspects of REPRESENT F. etc.
I believe iForth considers PRECISION to mean decimal places. Did you
depart from the Standard - or you were confused by it?
That holes still exist after 30 years can only mean forthers are
content with less than perfect documentation. No?
Documentation is for others :--)
Hans, if nothing else you know how to stir up forthers :-)
"Others". That's a philosophical question. Answering it greatly
influences ones view on documentation:
On 06-04-2025 09:10, mhx wrote:
Documentation is for others :--)
"Others". That's a philosophical question. Answering it greatly
influences ones view on documentation:
"You thought that it could never happen to all the people you became."
That's how I view "persons". I assume I'm the same person that went to
bed, however, I have no evidence whatsoever that I am. Does a computer,
fed with the data his predecessors collected, assume he's the same
computer as the ones he replaced?
Still, I feel a close connection to the persons that were me before me
and the persons that eventually will become me. I don't want to make
their work unnecessarily difficult. That's why I document. I've praised
them several times - either for making a tutorial for a specific library
- or at least leaving an example or demo.
That's why I think the Hans Bezemer of yesterday was not only a clever
lad, but also a nice guy. ;-)
Hans Bezemer
On 06-04-2025 09:10, mhx wrote:
Documentation is for others :--)
"Others". That's a philosophical question. Answering it greatly influences ones view on documentation:
"You thought that it could never happen to all the people you became."
That's how I view "persons". I assume I'm the same person that went to bed, however, I have no evidence whatsoever that I am. Does a computer, fed with the data his predecessors collected, assume he's the same computer as the ones he replaced?
Still, I feel a close connection to the persons that were me before me and the persons that eventually will become me. I don't want to make their work unnecessarily difficult. That's why I document. I've praised them several times - either for making a tutorial for a specific library - or at least leaving an example or demo.
That's why I think the Hans Bezemer of yesterday was not only a clever lad, but also a nice guy. ;-)
Unfortunately (?) my approach only works for small, dedicated
programs. There are examples where I wanted to write a bigger
application (e.g. MANX, SPIFSIM, SYSSIM, iSPICE, ..). I am
constantly trying to refactor those programs in small stand-alone
modules but I have failed (e.g. MANX which has horrible
object-oriented rubbish) when I (perhaps temporarily) lost
interest in the subject itself.
As I am also a ngspice maintainer (19,161 'C' Files in 4,856
directories, only user documentation), I know my Forth
approach works (iSPICE has only 7 dedicated files).
-marcel
That holes still exist after 30 years can only mean forthers are
content with less than perfect documentation. No?
DuskOS with TCP/IP, gopher/irc and maybe some basic soundcard
support would be great for low end i386 machines.
dxf <dxforth@gmail.com> wrote:
That holes still exist after 30 years can only mean forthers are
content with less than perfect documentation. No?
I don't worry much about documentation. If I don't understand my
code it's no big deal, I probably didn't know what I was doing in
the first place. As long as the computer can understand it and get
it right, most of the time, I've done my job.
"In particular you need to avoid writing code for situations that will
never arise in practice. You need to avoid writing code to handle a
general problem that you are never going to encounter. I don't need
to solve the general problem when I only have to solve these specific
cases." -- Chuck Moore
On the topic of documentation Forth Standard (the document to which
everyone looks) hasn't clarified aspects of REPRESENT F. etc.
That holes still exist after 30 years can only mean forthers are
content with less than perfect documentation. No?
dxf <dxforth@gmail.com> writes:
On the topic of documentation Forth Standard (the document to which
everyone looks) hasn't clarified aspects of REPRESENT F. etc.
The document does not write itself.
If you think that something is
unclear, you can make a request for clarification on <https://forth-standard.org/> (when it runs again, hopefully soon).
If you think that some text should be changed in a specific way, you
can make a proposal for that. If you have no interest in doing that
for these topics (which seem to be important enough to mention them
here), why should anybody else have an interest in doing that?
That holes still exist after 30 years can only mean forthers are
content with less than perfect documentation. No?
In the case of "F.", I actually believe that most users would prefer something that produces an output, possibly in scientific
representation, of up to 20 characters over the exact implementation
of the specification that is implemented by Gforth and VFX:
1e200 f. 100000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000. ok
1e-200 f. 0.00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001 ok
But nobody has written a proposal for changing "F." in that way. The feedback on such a proposal would indicate whether my belief is
correct or not. The absence of such a proposal indicates that the
topic is not important enough for Forth programmers and implementors.
On 6/04/2025 11:43 pm, sjack wrote:That used to happen every other weeek in Star Trek TOS.
dxf <dxforth@gmail.com> wrote:
That holes still exist after 30 years can only mean forthers are
content with less than perfect documentation. No?
I don't worry much about documentation. If I don't understand my
code it's no big deal, I probably didn't know what I was doing in
the first place. As long as the computer can understand it and get
it right, most of the time, I've done my job.
Folks like a security blanket - authority handed down. Often just
holding and cherishing the documentation, repeating the verses, is
enough. Throw a curveball and it's like watching Forbidden Planet
where Robby the Robot is presented with contradictory instructions.
Luckily Standard Forth is mostly harmless as nobody takes it seriously.
On 7/04/2025 4:42 pm, Anton Ertl wrote:done.
dxf <dxforth@gmail.com> writes:
On the topic of documentation Forth Standard (the document to which
everyone looks) hasn't clarified aspects of REPRESENT F. etc.
The document does not write itself.
No, and neither has anyone as the Synod doesn't say what needs to be
Can you imagine if Forth-94 had used that approach? AFAIK sub-committees were allocated tasks.ok
If you think that something is
unclear, you can make a request for clarification on
<https://forth-standard.org/> (when it runs again, hopefully soon).
If you think that some text should be changed in a specific way, you
can make a proposal for that. If you have no interest in doing that
for these topics (which seem to be important enough to mention them
here), why should anybody else have an interest in doing that?
That holes still exist after 30 years can only mean forthers are
content with less than perfect documentation. No?
In the case of "F.", I actually believe that most users would prefer
something that produces an output, possibly in scientific
representation, of up to 20 characters over the exact implementation
of the specification that is implemented by Gforth and VFX:
1e200 f. 100000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000.
ok1e-200 f. 0.00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001
1E3 F. )
But nobody has written a proposal for changing "F." in that way. The
feedback on such a proposal would indicate whether my belief is
correct or not. The absence of such a proposal indicates that the
topic is not important enough for Forth programmers and implementors.
That wasn't it. Rather the relation between 'significant digits' and
output is never really specified. Even the example Forth-94 gave (
didn't help because no mention of the PRECISION used.2017-12-03
NT/FORTH (C) 2005 Peter Fälth Version 1.6-983-824 Compiled on
3 set-precision
1e3 f. 1000. ok
6 set-precision ok
1e f. 1.00000 ok
1e4 f. 10000.0 ok
1e-4 f. 0.000100000 ok
0e f. 0.00000 ok
Gforth 0.7.9_20200709
3 set-precision
1e3 f. 1000. ok
6 set-precision ok
1e f. 1. ok
1e4 f. 10000. ok
1e-4 f. 0.0001 ok
0e f. 0. ok
Not sure whether it would affect a Standard Program but I imagine porting
a real-world app could be a problem.
I don't worry much about parachutes. If I don't understand
folding it's no big deal, I probably didn't know what I was
doing in the first place. As long as my wife can understand
it and get it right, MOST OF THE TIME, I've done my job.
On 07-04-2025 13:05, dxf wrote:
As a matter of fact, the whole issue can be solved by one single very simple addition to the standard. All my FP systems hold this very definition for SET-PRECISION:
\ 34: Reimplemented PRECISION and SET-PRECISION.
maxdigits VALUE PRECISION
: SET-PRECISION ( n -- ) maxdigits MIN TO PRECISION ;
Since the FLOAT wordset is always in decimal (12.4.1.2 Ambiguous conditions - BASE is not decimal (12.6.1.2143 REPRESENT, 12.6.2.1427 F., 12.6.2.1513 FE., 12.6.2.1613 FS.) it is trivial to calculate the number of significant digits.
The definition given here ( --- CONSTANT MAXDIGITS) ensures that the value issued to SET-PRECISION is always sane.
Of course, if one does not have access to some carnal knowledge concerning the mantissa, one does have a problem concerning porting and maintenance.
6 set-precision ok
1e-4 f. 0.000100000 ok
6 set-precision ok
1e-4 f. 0.0001 ok
...
It's not SET-PRECISION (presumably the implementer has made that sane)
but rather variability when values are sane e.g.
6 set-precision ok
1e-4 f. 0.000100000 ok
6 set-precision ok
1e-4 f. 0.0001 ok
While both of those are numerically correct, they're plainly different i.e. 11 characters vs. 6 characters. As an app writer I'd like some uniformity here as I might want to output several columns of numbers on a screen. To
do that I need to know how wide to make those columns.
...
On 9/04/2025 1:15 am, dxf wrote:
...
It's not SET-PRECISION (presumably the implementer has made that sane)
but rather variability when values are sane e.g.
6 set-precision ok
1e-4 f. 0.000100000 ok
6 set-precision ok
1e-4 f. 0.0001 ok
While both of those are numerically correct, they're plainly different i.e. >> 11 characters vs. 6 characters. As an app writer I'd like some uniformity >> here as I might want to output several columns of numbers on a screen. To >> do that I need to know how wide to make those columns.
...
Iforth's F. was previously mentioned. In addition to treating PRECISION as
a decimal points specifier (ok it was their decision) F. includes mode switching based on something called 'fieldwidth' for which I could find no reference. Is mode switching good or bad? As always - it depends. I've
yet to see a bank statement with the balance displayed in scientific notation. (But then I'm not Elon Musk so who knows.)
I mention this to demonstrate the variability that exists across forth - presumably because Forth-94 chose not to think it through leaving folks
to their own devices. REPRESENT ? Well, I could rant about that too :)
On 09-04-2025 04:21, dxf wrote:
On 9/04/2025 1:15 am, dxf wrote:
...
It's not SET-PRECISION (presumably the implementer has made that sane)
but rather variability when values are sane e.g.
6 set-precision ok
1e-4 f. 0.000100000 ok
6 set-precision ok
1e-4 f. 0.0001 ok
While both of those are numerically correct, they're plainly different i.e. >>> 11 characters vs. 6 characters. As an app writer I'd like some uniformity >>> here as I might want to output several columns of numbers on a screen. To >>> do that I need to know how wide to make those columns.
...
Iforth's F. was previously mentioned. In addition to treating PRECISION as >> a decimal points specifier (ok it was their decision) F. includes mode
switching based on something called 'fieldwidth' for which I could find no >> reference. Is mode switching good or bad? As always - it depends. I've >> yet to see a bank statement with the balance displayed in scientific
notation. (But then I'm not Elon Musk so who knows.)
I mention this to demonstrate the variability that exists across forth -
presumably because Forth-94 chose not to think it through leaving folks
to their own devices. REPRESENT ? Well, I could rant about that too :)
I've never been an avid FP wordset user, so I must admit I've never delved so deep into it. But when I did (last night) I thought "Darn, he's right!"
1. I remember my spreadsheet having a way to set the number of decimals. So I looked there. It used F.R to use that result - and to my surprise (it seems .R little brother) AFAIK it's not part of the FP wordset;
2. So I looked in the standard (obvious when you're coming from F.R) and no - nothing special there: "Set the number of significant digits". Well that's helpful. But do you mean "significant digits" the way I mean "significant digits"? I don't think so.. The beauty of "most significant digits of the significand" didn't escape me, though. Merriam Webster, "significant": "of a noticeably or measurably large amount". Almost like "most", you mean. ;-)
3. If I can't find any help there, try elsewhere. Like C++. There "Precision" really means "Precision" - aka "the number of significant digits in the mantissa". Which in my book means 19 for a 64-bit mantissa and 9 for a 32-bit mantissa - if someone is unsure of what I mean. "fixed" however, is the keyword in C++ that switches this meaning to the number of decimals. If I understand you correctly, that's how iForth actually works.
I see two ways out of this:
a. Add F.R to the standard;
b. Add SET-DECIMALS or SET-FIXED to the standard.
And finally, add a section to the Annex to define and clarify the whole darn thing (because IMHO that is dearly missing).
On 06-04-2025 15:43, sjack wrote:
I don't worry much about parachutes. If I don't understand folding it's
no big deal, I probably didn't know what I was doing in
the first place. As long as my wife can understand it and get it right,
MOST OF THE TIME, I've done my job.
Hans Bezemer
I see two ways out of this:
a. Add F.R to the standard;
b. Add SET-DECIMALS or SET-FIXED to the standard.
And finally, add a section to the Annex to define and clarify the whole
darn thing (because IMHO that is dearly missing).
Hans Bezemer
that's helpful. But do you mean "significant digits" the way I mean "significant digits"? I don't think so.. The beauty of "most significant
On Tue, 8 Apr 2025 11:48:29 +0000, Hans Bezemer wrote:
[..]
I don't worry much about parachutes. If I don't understand
folding it's no big deal, I probably didn't know what I was
doing in the first place. As long as my wife can understand
it and get it right, MOST OF THE TIME, I've done my job.
I case she did not, that happens only once: clearly
not worth the time to correct.
-marcel
In article <nnd$3aa8c556$6770ff88@2813463487325c8d>,
Hans Bezemer <the.beez.speaks@gmail.com> wrote:
On 06-04-2025 15:43, sjack wrote:
I don't worry much about parachutes. If I don't understand folding it's
no big deal, I probably didn't know what I was doing in
the first place. As long as my wife can understand it and get it right,
MOST OF THE TIME, I've done my job.
If I understand you correctly, you are okay if your wife gets it
right 4 of 5 times?
On 08-04-2025 15:45, mhx wrote:[..]
That may be an incorrect assumption - she might actually be *working*
there. It might be her only source of income since she inherited the
business from you - and people may be skydiving every day - unaware that they're actually be up for dirt diving.
On Sun, 6 Apr 2025 5:21:05 +0000, dxf wrote:
On 5/04/2025 6:12 pm, mhx wrote:[..]
On the topic of documentation Forth Standard (the document to which
everyone looks) hasn't clarified aspects of REPRESENT F. etc.
I don't let the Standard confuse me. It's beneficial when others
adhere to it closely, unless it's not. In particular, I don't agree
to the efforts to try to standardize untested 'good ideas.'
...
Hans Bezemer <the.beez.speaks@gmail.com> wrote:
that's helpful. But do you mean "significant digits" the way I mean
"significant digits"? I don't think so.. The beauty of "most significant
If you take a measurement and get a four digit number where the last
digit was result of rounding, then you have three significant digits.
But "words lie"; just their nature.
In article <nnd$4e97017c$71179fa7@ab267a929dfc81b6>,
Hans Bezemer <the.beez.speaks@gmail.com> wrote:
<SNIP>
I see two ways out of this:
a. Add F.R to the standard;
b. Add SET-DECIMALS or SET-FIXED to the standard.
And finally, add a section to the Annex to define and clarify the whole
darn thing (because IMHO that is dearly missing).
I'm with Anton Ertl here. If you have a clear idea what has to be done, formulate it and send in a proposal. (But I'm as guilty as you
regards other matters ...).
On 9/04/2025 9:28 pm, albert@spenarnc.xs4all.nl wrote:
In article <nnd$4e97017c$71179fa7@ab267a929dfc81b6>,
Hans Bezemer <the.beez.speaks@gmail.com> wrote:
<SNIP>
I see two ways out of this:
a. Add F.R to the standard;
b. Add SET-DECIMALS or SET-FIXED to the standard.
And finally, add a section to the Annex to define and clarify the whole
darn thing (because IMHO that is dearly missing).
I'm with Anton Ertl here. If you have a clear idea what has to be done,
formulate it and send in a proposal. (But I'm as guilty as you
regards other matters ...).
Why must it be done? To please you? If the committee is satisfied with
the status quo nothing need be done. And that's what you're seeing.
On 9/04/2025 11:14 pm, sjack wrote:
Hans Bezemer <the.beez.speaks@gmail.com> wrote:
that's helpful. But do you mean "significant digits" the way I mean
"significant digits"? I don't think so.. The beauty of "most significant
If you take a measurement and get a four digit number where the last
digit was result of rounding, then you have three significant digits.
But "words lie"; just their nature.
But when Forth-94 instructs you to 'round the number to n significant digits' what is unclear? Not the numerical result.
What's ambiguous in Forth-94 is the returned representation i.e. should REPRESENT return '0's representing the insignificant digits; should F.
trim the redundant trailing '0's.
What's ambiguous in Forth-94 is the returned representation i.e. should REPRESENT return '0's representing the insignificant digits; should F.
trim the redundant trailing '0's.
On 10-04-2025 07:15, dxf wrote:
On 9/04/2025 11:14 pm, sjack wrote:
Hans Bezemer <the.beez.speaks@gmail.com> wrote:
that's helpful. But do you mean "significant digits" the way I meanIf you take a measurement and get a four digit number where the last
"significant digits"? I don't think so.. The beauty of "most significant >>>
digit was result of rounding, then you have three significant digits.
But "words lie"; just their nature.
But when Forth-94 instructs you to 'round the number to n significant digits'
what is unclear? Not the numerical result.
What's ambiguous in Forth-94 is the returned representation i.e. should
REPRESENT return '0's representing the insignificant digits; should F.
trim the redundant trailing '0's.
Just my gut feeling: REPRESENT - no. This is a word used to construct number representations. It should be as literal as possible, because the programmer will most probably interfere in the representation. If he wants those zeros he should get them rather than add them IMHO.
F. - yes. This is my most vanilla floating point printer. It's the "just gimme my number" word - no frills.
In article <f7a591a1dc38e555ac1aecce6c59bd3bf195d09c@i2pn2.org>,
dxf <dxforth@gmail.com> wrote:
On 9/04/2025 9:28 pm, albert@spenarnc.xs4all.nl wrote:
...
I'm with Anton Ertl here. If you have a clear idea what has to be done,
formulate it and send in a proposal. (But I'm as guilty as you
regards other matters ...).
Why must it be done? To please you? If the committee is satisfied with
the status quo nothing need be done. And that's what you're seeing.
You must do it, because you are not satisfied with the standard.
<insults deleted>
dxf <dxforth@gmail.com> wrote:
See your point but won't give an opinion as how REPRESENT output
What's ambiguous in Forth-94 is the returned representation i.e. should
REPRESENT return '0's representing the insignificant digits; should F.
trim the redundant trailing '0's.
should appear, not my place.
But as a user the wording of REPRESENT, and thus PRECISION and
SET-PRECISION, is a little off. Rounding is mentioned but all the
parameters are stated as significant digits. Don't think
it prevents a user from getting what he wants but could taint
discussion of the result's significance. Is the result all
significant digits or significant digits plus one? Either could be
correct depending on the circumstance and the latter would be
the most often wanted.
On 10/04/2025 8:40 pm, albert@spenarnc.xs4all.nl wrote:
In article <f7a591a1dc38e555ac1aecce6c59bd3bf195d09c@i2pn2.org>,
dxf <dxforth@gmail.com> wrote:
On 9/04/2025 9:28 pm, albert@spenarnc.xs4all.nl wrote:
...
I'm with Anton Ertl here. If you have a clear idea what has to be done, >>>> formulate it and send in a proposal. (But I'm as guilty as you
regards other matters ...).
Why must it be done? To please you? If the committee is satisfied with >>> the status quo nothing need be done. And that's what you're seeing.
You must do it, because you are not satisfied with the standard.
Chuck Moore might beg to differ.
'Matters of fact or truth or beauty cannot be voted on. They speak for
themselves.'
If one sees truth of what's been said, one acts on it. To wait for
authority to tell one what to do indicates only subservience.
<insults deleted>
I'm not aware anything was deleted.
On 10/04/2025 8:40 pm, albert@spenarnc.xs4all.nl wrote:
In article <f7a591a1dc38e555ac1aecce6c59bd3bf195d09c@i2pn2.org>,
dxf <dxforth@gmail.com> wrote:
On 9/04/2025 9:28 pm, albert@spenarnc.xs4all.nl wrote:
...
I'm with Anton Ertl here. If you have a clear idea what has to be done, >>>> formulate it and send in a proposal. (But I'm as guilty as you
regards other matters ...).
Why must it be done? To please you? If the committee is satisfied with >>> the status quo nothing need be done. And that's what you're seeing.
You must do it, because you are not satisfied with the standard.
Chuck Moore might beg to differ.
'Matters of fact or truth or beauty cannot be voted on. They speak for
themselves.'
If one sees truth of what's been said, one acts on it. To wait for
authority to tell one what to do indicates only subservience.
<insults deleted>
I'm not aware anything was deleted.
With REPRESENT we're dealing with full-precision numbers being displayed
in lesser precision. Would 'significant digits plus one' even apply?
With REPRESENT we're dealing with full-precision numbers being displayedI did more digging into the subject that I probably should have done -
in lesser precision. Would 'significant digits plus one' even apply?
On 11-04-2025 04:19, dxf wrote:
On 10/04/2025 8:40 pm, albert@spenarnc.xs4all.nl wrote:
In article <f7a591a1dc38e555ac1aecce6c59bd3bf195d09c@i2pn2.org>,
dxf <dxforth@gmail.com> wrote:
On 9/04/2025 9:28 pm, albert@spenarnc.xs4all.nl wrote:
...
I'm with Anton Ertl here. If you have a clear idea what has to be done, >>>>> formulate it and send in a proposal. (But I'm as guilty as you
regards other matters ...).
Why must it be done? To please you? If the committee is satisfied with >>>> the status quo nothing need be done. And that's what you're seeing.
You must do it, because you are not satisfied with the standard.
Chuck Moore might beg to differ.
'Matters of fact or truth or beauty cannot be voted on. They speak for
themselves.'
If one sees truth of what's been said, one acts on it. To wait for
authority to tell one what to do indicates only subservience.
<insults deleted>
I'm not aware anything was deleted.
A proposition can be true a priori (conceptual only, like every bachelor is unmarried - even if I've never seen the guy). A fact is a state of actuality - and hence can only be evaluated as true or false a posteriori, since such proposition has to be confronted with the real world to establish its "truth" value (in the words of Wittgenstein - with a touch of Quine).
In the eyes of John Locke beauty is a secondary quality - and hence (as the saying goes) "in the eye of the beholder". You may establish it intersubjectively - but never objectively. Consequently, it cannot be "self evident".
So in short, no, you cannot vote on truth or fact (in spite of what postmodernism claims), but you can most certainly vote on beauty.
dxf <dxforth@gmail.com> wrote:
Unsure what is meant by "full-precision numbers" so the following
With REPRESENT we're dealing with full-precision numbers being displayed
in lesser precision. Would 'significant digits plus one' even apply?
reasoning my be off in that respect:
Floating-point has _potential_ to express a number with _maximum_ of u significant digits plus one rounded digit. However, in application a
result may have less than the maximum potential significant digits and
should be returned (displayed) with all digits _after the first non-significant digit_ chopped (or padded with zero's).
For sure I'm no authority on floating-point numbers. The only thing
I know is what I recall from remedial math in the olden days of light
that one wants a result of u significant digits plus the one rounded
digit. Such form of number is then useful for other floating-point calculations.
This is likely to have been a factor in Intel's decision to use
80-bits internally.
On 11-04-2025 05:52, dxf wrote:
With REPRESENT we're dealing with full-precision numbers being displayedI did more digging into the subject that I probably should have done - but I think so. IMHO there is no consensus (either in the standard nor elsewhere) what "significant digits" are. However I found that:
in lesser precision. Would 'significant digits plus one' even apply?
1. The significant seems to be the main source of "significant digits";
2. Either large exponents (and digits to the right of integer upto the decimal point) - or small exponents (and digits to the left upto the decimal point) are often referred to as "placeholders" AKA - not part of the "significant digits";
3. Leading zeroes (before the decimal point, but preceding the significant digits) or trailing zeroes (after the decimal point, but following the significant digits) are not placeholders. Note that some "trailing zeroes" can be significant digits;
4. The rightmost digit of the "significant digits", even when incorrect - is part of the significant digits.
And yeah, then there are things like rounding, "trapped zeroes", exact numbers - Oof!
But I think it would help if a definition of significant digits would be added to the standard. Now everybody is guessing what it means..
This is likely to have been a factor in Intel's decision to use
80-bits internally.
Maybe they needed 80 bits to print a binary 64-bit float in BCD
for COBOL compilers.
However, one needs a few hundred bits to correctly represent a
binary 56-bit significand in decimal, so maybe it is only enough
for single-precision floats?
For sure, high-quality libraries do not rely on 80-bit extended
precision for decimal output - I remember even the MASM library
had special code for that.
...
I take no precautions limiting output to 15 and 18 digits respectively
for double and extended. This is floating-point after all and lack of accuracy at the limits is expected.
On Sat, 12 Apr 2025 4:43:16 +0000, dxf wrote:
[..]
I take no precautions limiting output to 15 and 18 digits respectively
for double and extended. This is floating-point after all and lack of
accuracy at the limits is expected.
I think it has to do more with things like
FORTH> 1e 9e f/ 1e1000 f/ fe. 0.0111111111111111111e-999 ok
or Gforth's
1e 9e f/ 1e100 f/ fe. 0.0111111111111111111e-999 11.1111111111111E-102 ok
of SwiftX's
1e 9e f/ 1e390 f/ fe. 111.11111111111112E-393
4. The rightmost digit of the "significant digits", even when incorrect
- is part of the significant digits.
Hans Bezemer
subsection "Rounding to significant figures" I'm not seeing anything unexpected
or ambiguous.
So 1.00 means a precision required is 5 micron.
On 12-04-2025 03:40, dxf wrote:
subsection "Rounding to significant figures" I'm not seeing anything unexpected
or ambiguous.
Neither do I. However, there is more in the world than Wikipedia:
https://www.britannica.com/science/significant-figures https://ccnmtl.columbia.edu/projects/mmt/frontiers/web/chapter_5/6665.html https://www.montgomerycollege.edu/_documents/academics/support/learning-centers/ackerman-learning-center-rockville/significant-figures.pdf
https://chem.libretexts.org/Bookshelves/Analytical_Chemistry/Supplemental_Modules_(Analytical_Chemistry)/Quantifying_Nature/Significant_Digits
https://www.physics.uoguelph.ca/significant-digits-tutorial https://www.chem.fsu.edu/chemlab/chm1020c/lecture%202/04.php https://chem.libretexts.org/Bookshelves/Introductory_Chemistry/Introductory_Chemistry_(LibreTexts)/02%3A_Measurement_and_Problem_Solving/2.04%3A_Significant_Figures_in_Calculations
https://pmc.ncbi.nlm.nih.gov/articles/PMC4483789/ https://www.my-gcsescience.com/decimal-places-significant-figures/
.. just to name a few..
Look, *IF* we're adding a definition to the standard and *IF* we use the Wikipedia definition - I have no problem with that. Rather a bad definition than no definition (not saying the Wikipedia one is bad). But I don't fool myself into thinking that Wikipedia is *automatically* the most authoritative source.
So 1.00 means a precision required is 5 micron.
Where are the microns coming from?
...
Look, *IF* we're adding a definition to the standard and *IF* we use the Wikipedia definition - I have no problem with that. Rather a bad definition than no definition (not saying the Wikipedia one is bad). But I don't fool myself into thinking that Wikipedia is *automatically* the most authoritative source.
mhx <mhx@iae.nl> wrote:
So 1.00 means a precision required is 5 micron.
Where are the microns coming from?
What Albert wrote implies that precision is 0.005 (half of 0.01).
But (what he did not wrote) default unit for mechanical work is
milimeter. 0.005 of milimeter is 5 micron.
On 13-04-2025 04:50, Waldek Hebisch wrote:
mhx <mhx@iae.nl> wrote:
So 1.00 means a precision required is 5 micron.
Where are the microns coming from?
What Albert wrote implies that precision is 0.005 (half of 0.01).
But (what he did not wrote) default unit for mechanical work is
milimeter. 0.005 of milimeter is 5 micron.
Agreed, the terms mu and micron are still quite popular among boomers,
but haven't actually been part of the SI since 1967. It's micrometre,
folks. Glow up!
On Sun, 13 Apr 2025 17:24:03 +0000, Hans Bezemer wrote:
On 13-04-2025 04:50, Waldek Hebisch wrote:
mhx <mhx@iae.nl> wrote:
So 1.00 means a precision required is 5 micron.
Where are the microns coming from?
What Albert wrote implies that precision is 0.005 (half of 0.01).
But (what he did not wrote) default unit for mechanical work is
milimeter. 0.005 of milimeter is 5 micron.
Agreed, the terms mu and micron are still quite popular among boomers,
but haven't actually been part of the SI since 1967. It's micrometre,
folks. Glow up!
Irrelevant. Albert pointed out that the number "1.00" means nothing
without a context that allows to decide how the number should be
printed or evaluated.
...
For ex. "1.00" when presented to a computer will be extended to the
intrinsic precision of the computer's floats and be used thereafter
at that precision.
For ex. "1.00" when presented to a computer will be extended to the
intrinsic precision of the computer's floats and be used thereafter
at that precision.
Here you assume that you can not do a calculation that will
reduce that precision,
or that the hardware keep track of all
operations and calculate the remaining precision as it goes.
Present
1. F.
to a Forth system.
We oldtimers know what will happen, but it remains a fossil artefact for sure.
Present
1. F.
to a Forth system.
We oldtimers know what will happen, but it remains a fossil artefact for sure.
...
BTW, the standard (section A.12.3.7, A.12.6.1.0558, 12.3.7) requires the trailing E.
As far as the embedded decimal point goes:
"The Technical Committee has more than once received the suggestion that the text interpreter in Standard Forth systems should treat numbers that have an embedded decimal point, but no exponent, as floating-point numbers rather than double cell numbers. This suggestion, although it has merit, has always been voted down because it would break too much existing code; many existing implementations put the full digit string on the stack as a double number and use other means to inform the application of the location of the decimal point."
In short: !!WE DON'T WANNA BREAK EXISTING CODE!!
On the other hand, "TC reply to Q0004":
Q: Will a number with an *embedded* decimal point be converted to a double-cell number in a Standard Forth system?
A: Not necessarily. A Standard System is permitted, *but not required,* to convert digit strings with embedded periods as double numbers. Consequently, a Standard Program cannot rely on any particular interpretation of such digit strings.
On 15/04/2025 12:14 am, Hans Bezemer wrote:
...point, but no exponent, as floating-point numbers rather than double cell numbers. This suggestion, although it has merit, has always been voted down because it would break
BTW, the standard (section A.12.3.7, A.12.6.1.0558, 12.3.7) requires the trailing E.
As far as the embedded decimal point goes:
"The Technical Committee has more than once received the suggestion that the text interpreter in Standard Forth systems should treat numbers that have an embedded decimal
too much existing code; many existing implementations put the full digit string on the stack as a double number and use other means to inform the application of the location
of the decimal point."
cannot rely on any particular interpretation of such digit strings.
In short: !!WE DON'T WANNA BREAK EXISTING CODE!!
On the other hand, "TC reply to Q0004":
Q: Will a number with an *embedded* decimal point be converted to a double-cell number in a Standard Forth system?
A: Not necessarily. A Standard System is permitted, *but not required,* to convert digit strings with embedded periods as double numbers. Consequently, a Standard Program
AFAIR Forth-83 and prior never specified what form a double number should take i.e.
there was no 'standard code' to break. One could say Forth-94 was setting a standard
where none previously existed.
1_0 2_0 F+ FS. \ algol 68 compatible.
The exponent 0 can be ommitted:
1_ 2_ F+ FS. 3.0000000000000000000_
30print(1_0+2_0)
With _/~ you can print numbers like
567.123~
and read in just the same.
1_0 2_0 + . \ output: 30
1_0 2_0 + . \ output: 30
Sorry, I really don't like this. It takes away my
underlying mental model of how things should work.
What happens for "10_ 20_ + ." ?
1_0 2_0 + . \ output: 30
Sorry, I really don't like this. It takes away my
underlying mental model of how things should work.
What happens for "10_ 20_ + ." ?
What happens for "10_ 20_ + ." ?It outputs 30, too. The intended use of _ in Gforth is like this:...
What does your underlying mental model say how things should work?
mhx@iae.nl (mhx) writes:
1_0 2_0 + . \ output: 30
Sorry, I really don't like this. It takes away my
underlying mental model of how things should work.
What happens for "10_ 20_ + ." ?
It outputs 30, too. The intended use of _ in Gforth is like this:
100_000_000_000 20_000_000_000 + . \ outputs 120000000000
or with groups of 4 for those environments where that is conventional.
What does your underlying mental model say how things should work?
- anton
mhx@iae.nl (mhx) writes:
1_0 2_0 + . \ output: 30
Sorry, I really don't like this. It takes away my
underlying mental model of how things should work.
What happens for "10_ 20_ + ." ?
It outputs 30, too. The intended use of _ in Gforth is like this:
100_000_000_000 20_000_000_000 + . \ outputs 120000000000
or with groups of 4 for those environments where that is conventional.
What does your underlying mental model say how things should work?
100_000_000_000 20_000_000_000 + . \ outputs 120000000000
On 16/04/2025 5:47 am, mhx wrote:
1_0 2_0 + . \ output: 30
Sorry, I really don't like this. It takes away my
underlying mental model of how things should work.
What happens for "10_ 20_ + ." ?
By "mental model" presumably you mean cultural conditioning? Since
as far as I'm aware nobody is born with it. While some fret over
1. F. I can't say it's been an issue since leaving Microsoft BASIC
in the 1980's. Perhaps my missing the whole C thing had something
to do with it - in which case I'm grateful. The endless comparison
of Forth with other languages only serves to belittle it.
On Tue, 15 Apr 2025 21:59:21 +0000, Anton Ertl wrote:[...]
Your example
100_000_000_000 20_000_000_000 + . \ outputs 120000000000
is not very appetizing because it combines a useful concept
(allowing a visual cue in number I/O) with the need to
redefine many standard words.
You can tune the behavior of most C compilers as well - comply to a
certain standard. Don't tell me you can't do that with Forth (because
you can).
Hans Bezemer <the.beez.speaks@gmail.com> writes:
You can tune the behavior of most C compilers as well - comply to a
certain standard. Don't tell me you can't do that with Forth (because
you can).
C standards avoid incompatible changes as good as they can. However,
because C is a keyword-based language and redefining existing names
produces an error in C, even adding a single keyword or a single name
can break compatibility with an existing program, and the compilers
allow you to dial the specific standard in order to deal with that.
Forth is better suited to deal with such changes, but then some people
come along and use the misfeatures of C as encouragement for their
desire to break existing programs.
OTOH, Forth is worse suited to deal with dial-your-language-version
options: C uses separate compilation, so if the main program uses some version of the standard, and a library uses a different version,
that's typically no problem, because they are both compiled with
different compiler calls (which may have different options).
Forth, OTOH, compiles all the sources in one compilation run, and any
choices you dial at one point tend to affect all the rest of the
compilation, even if it compiles some independently developed library.
One could dream up ways to deal with that problem, but given past
experience, I doubt such ideas would find enough support; some would
call that "WIBNI"s, while others would point out that Chuck Moore did
not bring these ideas down from the mountain.
- anton
Hans Bezemer <the.beez.speaks@gmail.com> writes:
You can tune the behavior of most C compilers as well - comply to a
certain standard. Don't tell me you can't do that with Forth (because
you can).
C standards avoid incompatible changes as good as they can. However,
because C is a keyword-based language and redefining existing names
produces an error in C, even adding a single keyword or a single name
can break compatibility with an existing program, and the compilers
allow you to dial the specific standard in order to deal with that.
- anton
Oh? For example 'static' in a c-source has the meaning of making a name invisile to the outside world.
A normal person would call that 'local', especially given that static actually meant residing in heap memory.
So as the c-expert hired for Fico moldings I introduced a file
fico.h with a line
#define static local
(and the line
#define TRUE 1
because they came from Pascal and thought that TRUE was -1 ).
On 16-04-2025 23:26, Anton Ertl wrote:
OTOH, Forth is worse suited to deal with dial-your-language-version
options: C uses separate compilation, so if the main program uses some
version of the standard, and a library uses a different version,
that's typically no problem, because they are both compiled with
different compiler calls (which may have different options).
Forth, OTOH, compiles all the sources in one compilation run, and any
choices you dial at one point tend to affect all the rest of the
compilation, even if it compiles some independently developed library.
One could dream up ways to deal with that problem, but given past
experience, I doubt such ideas would find enough support; some would
call that "WIBNI"s, while others would point out that Chuck Moore did
not bring these ideas down from the mountain.
- anton
I don't think so. Using K&R prototypes is significantly different from
ANSI prototypes. That must have broken quite some code - unless specific >measures were taken to allow "old format" codes as well.
restrict,
nullptr, inline, bool - the list of added keywords is endless.
BTW, so
is the list of deprecated keywords, like "_Bool" with was replaced by
the far less ugly "bool" in 2023.
And I don't think the argument that "Forth compiles in one go" holds up
as an argument to avoid cleaning up historical clutter. The different >versions of a "keyword" could be created as their names, followed by a >postfix of the standard, e.g. DO_79, DO_82, DO_94. Let's call 'em
"version words".
One could dream up ways to deal with that problem, but given past
experience, I doubt such ideas would find enough support
There could be special words like [FORTH78], [ANSFORTH] - which would no >nothing but:
- Either hiding words in the dictionary that should be disabled;
- Activating words that are part of this standard;
- Assigning the proper "version" words to trampolines or DEFERs.
But I think maybe, just maybe the same effect could be achieved by using >wordsets.
So, if we compile an external library using a mix of Forth-79, ANS Forth
and Forth 2012, it could be as simple as:
INCLUDE a.fs
INCLUDE b.fs
[FORTH2012]
a.fs:
[FORTH79]
...
b.fs:
[ANSFORTH]
...
That's much like setting the radix.
So - why couldn't this work?
So you could try to propose a word like FORTH-2030-FP-SYNTAX, but I
expect that the reactions would be along the following lines (in the community and in the standardization committee)
One way to keep backwards compatibility with the current common
practice would be to require having a word FORTH-2030-FP-SYNTAX (or
maybe just FORTH-2030) in every file that uses the new FP syntax
before the use of that syntax. If that word does not appear in that
file, "1.0" would still be non-standardized.
Next: "1.". If we had such declarations, we could even support "1." >(standardized as double-cell in Forth-94 and Forth-2012) as FP number.--
The alternative would be to treat "1." as double-cell and 1.0 as FP
value, which IMO is even worse than requiring an "e" in every FP
value.
But back to the dial-a-standard things: I have never seen such a
proposal that limits the dialing to one file. Instead, the proposals
and existing practice is to dial for the rest of text interpretation
(or until somthing else is dialed). That would mean that previously
working files might no longer work when included after dialing the new
FP syntax. E.g., all versions of the recognizer proposal have been
along these lines, and Bernd Paysan has actually proposed allowing to
treat "1." as FP value by swapping the integer and FP recognizer in
the recognizer order, which would have exactly this effect. And Bernd
Paysan is not the only one: Among other dialing features that all are
not limited to the file, VFX supports disabling the recognition of
"1." as double, which then leads to its recognition as FP number; but
that disabling is not limited to a file, but extends to the rest of
the text interpretation.
Here's the example for VFX:
',' dp-char 1+ c! ok
1. ok F:-1
f. 1. ok
So you could try to propose a word like FORTH-2030-FP-SYNTAX, but I
expect that the reactions would be along the following lines (in the >community and in the standardization committee):
1) A number of people consider this completely unnecessary, and
actually heretical, because Chuck Moore came down from the mountain
with doubles, not floats, so that's the way it was always meant to
be. Some would argue that treating "1.0" or "1." as FP number is
proposed just to cater to C programmers, and that Forthers should
take pride in deviating from the beaten path.
2) A number of people would argue against the limitation to a specific
file because of "complexity" (meaning implementation complexity),
"WIBNI", or because Chuck Moore came down from the mountain without
that idea, and that Chuck Moore has argued against libraries, that
he has argued against saving and restoring state, and instead has
argued for always setting it. And that the common practice (e.g.,
in VFX) is to just set the state, and never
3) And if you changed your proposal to just affect the rest of text
interpretation (and include another word FORTH-2012-FP-SYNTAX or
somesuch to switch back), some people (including me) would argue
that this variant of FORTH-2030-FP-SYNTAX would break existing
code, and that introducing FORTH-2012-FP-SYNTAX is a poor and
error-prone substitute for defining FORTH-2030-FP-SYNTAX properly.
Word counters would dislike this variant because it introduces an
additional word, and the people who argue 1) would also dislike the
proposal.
The bottom line is that the proposal would probably not find a
consensus and would not be accepted by the committee. The bottom line
is:
One could dream up ways to deal with that problem, but given past
experience, I doubt such ideas would find enough support
And the bottom line of that is that proposals for incompatible changes
have little chance of being accepted.
There could be special words like [FORTH78], [ANSFORTH] - which would no >>nothing but:
- Either hiding words in the dictionary that should be disabled;
- Activating words that are part of this standard;
Interestingly, Forth-79 includes a word 79-STANDARD, and Forth-83
includes a word FORTH-83, but Forth-94 and Forth-2012 do not include
such words. We had a discussion whether we should have Forth-94 and >Forth-2012 versions of environmental queries for wordsets in
Forth-2012, but the committee decided against that.
In any case, if you want to support including libraries written for a >different standard, the effect of such words should be limited to a
specific file. If the standards are incompatible and you want
libraries, and you do not provide this kind of dialing, you can take a
look at the Python 3 transition pain (or worse, what happened with
Perl6) to see what happens. The Python community has learned from
that experience not to introduce such incompatible changes again.
- Assigning the proper "version" words to trampolines or DEFERs.
That's exactly the wrong thing to do. You want to statically bind the
name to the word with the right version. E.g. if you have a Forth-83 program
forth-83
100 load ( includes a library written in Forth-79)
: foo ( ... -- ... )
... not ... ;
and the library contains
79-standard
: bar ( ... -- ... )
... not ... ;
you want the use of NOT in FOO to be statically bound to (what
Forth-94 calls) INVERT and the NOT in BAR to be statically bound to
0=; you usually don't want BAR or FOO to change its behaviour
depending on which standard is selected.
But I think maybe, just maybe the same effect could be achieved by using >>wordsets.
I assume you mean wordlists. Yes, the effect of switching between the >Forth-83 NOT and the Forth-79 NOT can be achieved by having a wordlist >containing the Forth-79 words and a wordlist containing the Forth-83
words, and putting it in the search order.
So, if we compile an external library using a mix of Forth-79, ANS Forth >>and Forth 2012, it could be as simple as:
INCLUDE a.fs
INCLUDE b.fs
[FORTH2012]
a.fs:
[FORTH79]
...
b.fs:
[ANSFORTH]
...
There is 79-STANDARD, but there is no word equivalent to [FORTH2012]
or [ANSFORTH]. So a program that contains "[FORTH2012]" without first >defining it is not Forth-2012-compliant. And a program that contains >[ANSFORTH] without first defining it is not Forth-94 compliant.
That's much like setting the radix.
BASE is one of the misfeatures of Forth, and demonstrates the
disadvantage of having a state for the rest of the text
interpretation, and the Chuck Moore approach to . Do you start every
file with DECIMAL or HEX? Looking at SwiftForth (where one might
expect the most Chuck Moore influence), I see 26 occurences of DECIMAL
and 16 occurences of HEX, and usually not before the first occurence
of an integer with several digits. As an example, the file that
contains the definition
: DECIMAL ( -- ) 10 BASE ! ;
does not contain an invocation of DECIMAL before this use of "10".
So - why couldn't this work?
As mentioned, there is no [FORTH2012] and no [ANSFORTH].
Moreover, this general approach does not work for BASE: If the next
standard required that systems start out in, say, octal, I am sure
that a lot of the existing source files would fail unless you invoked
DECIMAL before the INCLUDE. BASE only works (and only so-so) because
every sane system defaults to DECIMAL, and that does not change
between standard versions.
- 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: https://forth-standard.org/
EuroForth 2023 proceedings: http://www.euroforth.org/ef23/papers/
EuroForth 2024 proceedings: http://www.euroforth.org/ef24/papers/
That's much like setting the radix.
BASE is one of the misfeatures of Forth, and demonstrates the
disadvantage of having a state for the rest of the text
interpretation, and the Chuck Moore approach to . Do you start every
file with DECIMAL or HEX? Looking at SwiftForth (where one might
expect the most Chuck Moore influence), I see 26 occurences of DECIMAL
and 16 occurences of HEX, and usually not before the first occurence
of an integer with several digits. As an example, the file that
contains the definition
: DECIMAL ( -- ) 10 BASE ! ;
does not contain an invocation of DECIMAL before this use of "10".
So - why couldn't this work?
As mentioned, there is no [FORTH2012] and no [ANSFORTH].
Moreover, this general approach does not work for BASE: If the next
standard required that systems start out in, say, octal, I am sure
that a lot of the existing source files would fail unless you invoked
DECIMAL before the INCLUDE. BASE only works (and only so-so) because
every sane system defaults to DECIMAL, and that does not change
between standard versions.
| Sysop: | DaiTengu |
|---|---|
| Location: | Appleton, WI |
| Users: | 1,030 |
| Nodes: | 10 (0 / 10) |
| Uptime: | 26:41:07 |
| Calls: | 13,346 |
| Calls today: | 3 |
| Files: | 186,574 |
| D/L today: |
3,007 files (706M bytes) |
| Messages: | 3,357,804 |