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.
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.
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
Writing a gopher, irc
and some small usenet client would be a breeze.
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.
"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 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
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! ;
: FOPEN ( a n fam -- ) open-file s" open" ferr cf ! ;
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 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?
"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
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.
"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?
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.
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 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 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 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.
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 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?
This is likely to have been a factor in Intel's decision to use
80-bits internally.
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.
4. The rightmost digit of the "significant digits", even when incorrect
- is part of the significant digits.
Hans Bezemer
So 1.00 means a precision required is 5 micron.
So 1.00 means a precision required is 5 micron.
Where are the microns coming from?
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!
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.
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_ + ." ?
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 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.
- anton
On 26/04/2025 2:34 am, Hans Bezemer wrote:
...
Yeah, I have helped to make a proposal for PLACE and +PLACE - which never even made it to the voting stage.
It's a nice symmetry. OTOH the remaining vendors use APPEND and why should they change?
On 27-04-2025 08:21, dxf wrote:
On 26/04/2025 9:07 pm, albert@spenarnc.xs4all.nl wrote:
In article <b73cd7a7ab393f51bfaa18a9171086732bcc0bdf@i2pn2.org>,
dxf <dxforth@gmail.com> wrote:
On 26/04/2025 2:34 am, Hans Bezemer wrote:
...
Yeah, I have helped to make a proposal for PLACE and +PLACE - which never even made it to the voting stage.
It's a nice symmetry. OTOH the remaining vendors use APPEND and why should they change?
$+! was even earlier. It predates the IBM PC XT.
(Osborne, CP/M)
Even PLACE was new back then!
String stacks often had $+ or equiv. Somehow I never took to them.
Not enough applications that warranted the effort?
Let's face it - the string support was notoriously bad in Forth. People >openly complained about that.
Hans Bezemer--
On 27-04-2025 14:02, albert@spenarnc.xs4all.nl wrote:
In article <nnd$63e5382c$3fdcafbf@3f3b7214bd28514c>,
Hans Bezemer <the.beez.speaks@gmail.com> wrote:
On 27-04-2025 08:21, dxf wrote:
On 26/04/2025 9:07 pm, albert@spenarnc.xs4all.nl wrote:
In article <b73cd7a7ab393f51bfaa18a9171086732bcc0bdf@i2pn2.org>,
dxf <dxforth@gmail.com> wrote:
On 26/04/2025 2:34 am, Hans Bezemer wrote:
...
Yeah, I have helped to make a proposal for PLACE and +PLACE - which never even made it to the voting stage.
It's a nice symmetry. OTOH the remaining vendors use APPEND and why should they change?
$+! was even earlier. It predates the IBM PC XT.
(Osborne, CP/M)
Even PLACE was new back then!
String stacks often had $+ or equiv. Somehow I never took to them.
Not enough applications that warranted the effort?
Let's face it - the string support was notoriously bad in Forth. People
openly complained about that.
You must get rid of two ideas that are in the basic/lisp/c world.
1. You don't need dynamic strings. Just keep track of where you left them. >> [ If you really need them, don't do circular buffer or string stacks.
Interface to the memory wordset (ALLOCATE c.s). ]
2. Zero ended strings is a stupid 60's c-cludge. Copying that into Forth is >> beyond .. . They can't accomodate zero byte in strings, They cannot
accomodate multiple byte characters.
If you fetch a string, you have a "c-addr count". Forth can have 2 items
on the stack you know.
So In my CP/M day I get by with $! $@ $+! and $C+! .
I made a program playing a text adventure game with that.
Groetjes Albert
Hans Bezemer
-- 2. Zero ended strings is a stupid 60's c-cludge. Copying that into
Forth is beyond .. . They can't accomodate zero byte in strings, They
cannot accomodate multiple byte characters.
Well, the "club" has killed that one, so it bears no longer any
significance. FYI: I was not in favor of this proposition, it reeked >extremely Forth-83:
"Since then, in 2016 the Forth-200x committee in favour of eliminating >ambiguous conditions has decided to require “1 CHARS = 1” thus making >systems that have other character sizes than on not compliant to
_future_ Forth-200x standards [2][3]. Requesting standard systems to
have byte size characters limit counted strings to the known maximal
length of 255 characters."
Hans Bezemer
Just a shame the very basics are missing. The only thing holding Forth
back is the refusal to abstract strings.
On 27/04/2025 8:28 pm, Hans Bezemer wrote:
...of the "how"). E.g. for counted strings it might be:
Another handy word is >STRING that converts a "raw" string to a fully qualified string ( a1 n1 -- a2) that can handle a COUNT (you have the carnal knowledge - you take care
: >STRING swap over over dup char+ rot cmove c! ;
For forths that have PACK ( a u a2 -- a2 )
: >STRING ( a u -- a ) over pack ;
On 28/04/2025 8:39 pm, Hans Bezemer wrote:
On 28-04-2025 11:22, dxf wrote:Forth back is the refusal to abstract strings. Wanna make it a counted
On 27/04/2025 8:28 pm, Hans Bezemer wrote:
...
Just a shame the very basics are missing. The only thing holding
string with a cell count? Do it. Wanna keep on doing counted strings? Do
it. Wanna do ASCIIZ strings? No problem.
I've used
But aren't string primitives a la ANS-Forth the key to flexibility?
countless times.the concatenation primitive +STRING ( a u a2 u2 -- a2 u+u2 )
in ANS Forth, Forth 2012 -
: ZPLACE ( c-addr u c-addr2 -- ) zcount +string + 0 swap c! ;
: ZAPPEND ( c-addr u c-addr2 -- ) zcount + zplace ;
The problem is: it's defined nowhere. Not in Wil Baden Toolbelt, not
+STRING was defined in the Open Terminal Architecture spec - a joint project >by Forth Inc and MPE circa 2000.
+STRING plus-string
( c-addr1 len1 c-addr2 len2 - c-addr2 len3 )
Append the string at c-addr1, for len1 bytes, to the end of the string
at c-addr2, for len2 bytes. Return the beginning of the destination
string (c-addr2) and the sum of the two lengths (len3). It is the programmer's responsibility to ensure that there is room at the end of
the destination string to hold both strings.
Why it never made it into their forth offerings I don't know - perhaps >because the project was moth-balled?
and I can't find a good CoMuS list anymore, it seems.
If you mean Leo Wong's ...
http://www.murphywong.net/hello/comus.htm
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 475 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 19:52:52 |
| Calls: | 9,487 |
| Calls today: | 6 |
| Files: | 13,617 |
| Messages: | 6,121,093 |