On Thursday, December 23, 2021 at 2:34:54 AM UTC+3, Andy Valencia wrote:
> Nickolay Kolchin <nbko...@gmail.com> writes:
> > But 40 years ago people build complex systems in Forth. For example:
> > http://dl.forth.com/jfar/vol3/no2/article4.pdf
> > What has changed?
> I brought up a C-based microkernel VSTa about 20 years ago; pushing bytes out
> the UART to see where the kernel crashed as it clawed its way to life. It
> was pretty torturous, but as the only option, I went with it.
>
> I did some huge changes to exceptions and interrupts on ForthOS a few years
> ago. It was under qemu (and bochs for "single step the microcode" type
> debugging of my mistakes), and had to be like 100x more productive.
>
> Would I go back? No. I did it, and I know how to do it. But I will decline
> to do it for now and into the future.
>
> I've done pretty big apps in Forth. Now I do them mostly in Python. Things
> don't corrupt, you can ^C out, you skip all the memory allocation hassles.
> Modules and classes and all the "batteries included" amenities. I know how
> to do it the old way, but I will decline to do it on into the future.
>

Have you tried Factor?

On Wednesday, December 22, 2021 at 11:24:48 PM UTC+3, Paul Rubin wrote:
> Nickolay Kolchin <nbko...@gmail.com> writes:
> >> Today nobody with a sane mind would automate an airport in Forth.
> > From safety point of view Forth is no different from C/C++.
> Nobody with a sane mind would automate an airport in C today either.

No. C is still number one for embedded. And in regulated areas like aviation
for example, only two languages exist -- C and Ada. There are two reasons
for that:

1. Tools.
2. General conservatism in the industry. DERs know what to expect and what
to check in C projects. And nobody wants to take responsibility when shiny
new thing suddenly explodes.

So parts of code may be written in C.

> > Forth code with proper testing and coverage will be as safe as C.
> That's not saying much! And even assuming equivalence of the end
> product, which one gets there with less total effort? Which is easier
> to maintain and extend?

In theory, with proper tools, Forth should be more simple to test.

> > So, whats the problem? Language reputation, poor tools or lack of
> > programmers?
> You mentioned Frama-C for validating C code: is there something like it
> for Forth? What about for C++?
>

Forth has nothing like that, except few academical projects. Frama-C
have some C++ support, but is in early stages.

> I'm not that advanced a C++ programmer but I use it in preference to C
> these days and it really does help my productivity a lot, even if the
> end product is not any safer. Productivity still counts.

And something like Go will make you even more productive (that depends
on target application of course). Smaller compile time, easier external
libraries integration, etc.

On 12/22/21 10:00, Nickolay Kolchin wrote:
> On Wednesday, December 22, 2021 at 6:38:16 PM UTC+3, Krishna Myneni wrote:
>> On 12/22/21 09:30, Nickolay Kolchin wrote:
>>> On Wednesday, December 22, 2021 at 5:21:40 PM UTC+3, Krishna Myneni wrote:
>>>> On 12/21/21 12:46, Marcel Hendrix wrote:
>>>>> On Tuesday, December 21, 2021 at 6:05:06 PM UTC+1, minf...@arcor.de wrote:
>>>>>> My impression is that there are basically three different Forth worlds:
>>>>>> 1) few commercially supported development toolchains with a battle-proven
>>>>>> vendor-specific Forth core
>>>>>> 2) ISO/ANS Forth with little progress and barely usable for real world apps
>>>>>> 3) hundreds of personal/hobby/academic Forths or VMs, often severely
>>>>>> crippled and unmaintained
>>>>>>
>>>>>> Ad 1) Vendors are customer-driven, they fulfill contracts. Generic language
>>>>>> development has no priority.
>>>>>>
>>>>>> Ad 2) and 3) There seems a tendency towards permanently reinventing
>>>>>> or retuning old wheels. Hence no progress there as well.
>>>>>>
>>>>>> It is a dilemma. Where are Forth's main application niches today?
>>>>>> What is lacking in Forth that prevents it from filling these niches?
>>>>>
>>>>> I should hope there is a fourth world where people are using
>>>>> Forth for their own extremely domain-specific problems.
>>>>> These people fully control their copy or version of Forth
>>>>> and have no desire to further develop the basis of an
>>>>> arbitrarily extensible language. The only thing they
>>>>> are missing (I guess) in the current time segment
>>>>> is the Forth Dimensions/FORML/JFAR type of
>>>>> papers of the past era.
>>>>> (https://www.forth.com/forth-books/jfar-archives/).
>>>>>
>>>>> -marcel
>>>>>
>>>> The perennial hand wringing about Forth's dim prospects for being a
>>>> mainstream language, even for niche applications, continues. It is a bit
>>>> amusing, but also a bit tiresome.
>>>>
>>>
>>> But 40 years ago people build complex systems in Forth. For example:
>>>
>>> http://dl.forth.com/jfar/vol3/no2/article4.pdf
>>>
>>> What has changed?
>>>
>> My guess is the availability of other, better standardized programming
>> languages and tools which don't depart in convention as much from
>> traditional procedural programming is what has changed.
>>
>
> Can you elaborate what do you mean by "better standardized programming
> languages"?
>

Upon re-reading my statement, I realize it is ambiguous with respect to
"better". I meant that implementations and standards for conventional
procedural programming had improved over the original non-Forth
counterparts, e.g. better standardization amongst C compilers (although
that may have taken a while). There were also a plethora of new
languages with paradigms such as OOP, e.g. C++ and Java, which retained
familiarity with past languages. But, perhaps the most important reason
that Forth was quickly overtaken was that the large software/hardware
companies of the early 1990s, such as Microsoft, Borland, Sun
Microsystems, threw their weight behind the conventional language
descendants. This meant, for example, they could develop large libraries
of ready to use components. Small Forth companies could not compete in
the general programming space within that environment. The above
observations are mostly relevant to the development of applications for
commercial use.

Forth continues to evolve, as well as to fragment into variants. This
may be intrinsic to the nature of the language, and not altogether a bad
thing, unless one is only evaluating it through the lens of commercial use.

Krishna

On Thursday, December 23, 2021 at 7:10:16 AM UTC+3, Krishna Myneni wrote:
> On 12/22/21 10:00, Nickolay Kolchin wrote:
> > On Wednesday, December 22, 2021 at 6:38:16 PM UTC+3, Krishna Myneni wrote:
> >> On 12/22/21 09:30, Nickolay Kolchin wrote:
> >>> On Wednesday, December 22, 2021 at 5:21:40 PM UTC+3, Krishna Myneni wrote:
> >>>> On 12/21/21 12:46, Marcel Hendrix wrote:
> >>>>> On Tuesday, December 21, 2021 at 6:05:06 PM UTC+1, minf...@arcor.de wrote:
> >>>>>> My impression is that there are basically three different Forth worlds:
> >>>>>> 1) few commercially supported development toolchains with a battle-proven
> >>>>>> vendor-specific Forth core
> >>>>>> 2) ISO/ANS Forth with little progress and barely usable for real world apps
> >>>>>> 3) hundreds of personal/hobby/academic Forths or VMs, often severely
> >>>>>> crippled and unmaintained
> >>>>>>
> >>>>>> Ad 1) Vendors are customer-driven, they fulfill contracts. Generic language
> >>>>>> development has no priority.
> >>>>>>
> >>>>>> Ad 2) and 3) There seems a tendency towards permanently reinventing
> >>>>>> or retuning old wheels. Hence no progress there as well.
> >>>>>>
> >>>>>> It is a dilemma. Where are Forth's main application niches today?
> >>>>>> What is lacking in Forth that prevents it from filling these niches?
> >>>>>
> >>>>> I should hope there is a fourth world where people are using
> >>>>> Forth for their own extremely domain-specific problems.
> >>>>> These people fully control their copy or version of Forth
> >>>>> and have no desire to further develop the basis of an
> >>>>> arbitrarily extensible language. The only thing they
> >>>>> are missing (I guess) in the current time segment
> >>>>> is the Forth Dimensions/FORML/JFAR type of
> >>>>> papers of the past era.
> >>>>> (https://www.forth.com/forth-books/jfar-archives/).
> >>>>>
> >>>>> -marcel
> >>>>>
> >>>> The perennial hand wringing about Forth's dim prospects for being a
> >>>> mainstream language, even for niche applications, continues. It is a bit
> >>>> amusing, but also a bit tiresome.
> >>>>
> >>>
> >>> But 40 years ago people build complex systems in Forth. For example:
> >>>
> >>> http://dl.forth.com/jfar/vol3/no2/article4.pdf
> >>>
> >>> What has changed?
> >>>
> >> My guess is the availability of other, better standardized programming
> >> languages and tools which don't depart in convention as much from
> >> traditional procedural programming is what has changed.
> >>
> >
> > Can you elaborate what do you mean by "better standardized programming
> > languages"?
> >
> Upon re-reading my statement, I realize it is ambiguous with respect to
> "better". I meant that implementations and standards for conventional
> procedural programming had improved over the original non-Forth
> counterparts, e.g. better standardization amongst C compilers (although
> that may have taken a while). There were also a plethora of new
> languages with paradigms such as OOP, e.g. C++ and Java, which retained
> familiarity with past languages. But, perhaps the most important reason
> that Forth was quickly overtaken was that the large software/hardware
> companies of the early 1990s, such as Microsoft, Borland, Sun
> Microsystems, threw their weight behind the conventional language
> descendants. This meant, for example, they could develop large libraries
> of ready to use components. Small Forth companies could not compete in
> the general programming space within that environment. The above
> observations are mostly relevant to the development of applications for
> commercial use.

Your points are valid for desktop development. But how Forth lost
embedded?

>
> Forth continues to evolve, as well as to fragment into variants. This
> may be intrinsic to the nature of the language, and not altogether a bad
> thing, unless one is only evaluating it through the lens of commercial use.
>

Can you name Forth major evolution points since ANS?

Nickolay Kolchin <nbkolchin@gmail.com> writes:
>> Nobody with a sane mind would automate an airport in C today either.
>
> No. C is still number one for embedded. And in regulated areas like
> aviation for example, only two languages exist -- C and Ada. There are
> two reasons for that:

The airport project was not aviation (airports stay on the ground) and
only a few parts of it were embedded. It was programmed in Forth, for
heavens' sake ;-). These days, the embedded parts (sensor nodes) would
be clients to some fairly straightforward server app.

C for embedded may be fading, as embedded processors get powerful
enoough to run full featured OS's and more convenient languages.

> In theory, with proper tools, Forth should be more simple to test.

I don't know about this. Maybe it is possible.

> And something like Go will make you even more productive [than C++]

Yeah maybe sometimes, though the execution speed is considerably slower,
and for that program it mattered. I used Go some years ago though I
didn't become expert at it. The new versions may be better. I also
want to try Rust.

Ada is kind of daunting. I've played with it and read a book about it
("Ada Distilled"), understood most of the stuff in the book, but then
find I can't really follow newsgroup discussions about it because they
are about issues that the book doesn't discuss.

I have another Ada book sitting near my bed for the past year or so that
I've barely looked at. It does look good. Someday...

On Thursday, December 23, 2021 at 8:25:24 AM UTC+3, Paul Rubin wrote:
> Nickolay Kolchin <nbko...@gmail.com> writes:
> >> Nobody with a sane mind would automate an airport in C today either.
> >
> > No. C is still number one for embedded. And in regulated areas like
> > aviation for example, only two languages exist -- C and Ada. There are
> > two reasons for that:
> The airport project was not aviation (airports stay on the ground) and
> only a few parts of it were embedded. It was programmed in Forth, for
> heavens' sake ;-). These days, the embedded parts (sensor nodes) would
> be clients to some fairly straightforward server app.

I know that land systems have different regulation. Aviation was used
to demonstrate that C is not going away anytime soon.

>
> Ada is kind of daunting. I've played with it and read a book about it
> ("Ada Distilled"), understood most of the stuff in the book, but then
> find I can't really follow newsgroup discussions about it because they
> are about issues that the book doesn't discuss.
>
> I have another Ada book sitting near my bed for the past year or so that
> I've barely looked at. It does look good. Someday...

Ada found a niche in Safety Critical Development and stays strong there.
Read about SPARK: https://www.adacore.com/about-spark

They first made formal verification tools part of language standard.

P.S. I really like your quotation style. You should write a tutorial on that.

Nickolay Kolchin <nbkolchin@gmail.com> writes:
> I know that land systems have different regulation. Aviation was used
> to demonstrate that C is not going away anytime soon.

I'm terrified if anyone is crazy enough to program avionics in C. I
know that SpaceX uses C++ which is also terrifying, but not quite in the
same way. Ada really is the best for this from what I can tell.

I believe a lot of aerospace Ada code is generated from Matlab models,
fwiw. I have no idea how Ada's safety features interact with that.

> Ada found a niche in Safety Critical Development and stays strong there.
> Read about SPARK: https://www.adacore.com/about-spark

Yes I tried to build it from source some years ago and got bogged down
in dependency issues, but I will try again sometime.

On Thursday, December 23, 2021 at 9:06:32 AM UTC+3, Paul Rubin wrote:

(I accidentally removed this from original reply)
>
> C for embedded may be fading, as embedded processors get powerful
> enoough to run full featured OS's and more convenient languages.

full featured OS are unable to handle modern realtime requirements. I.e.
microsecond precision (It was fun to read about IPS "realtime" at 50hz in
a recent thread here).

Most boards we made in recent years have two controllers: one for realtime
processing, one for everything else. And realtime one is programmed
baremetal in C.

> > I know that land systems have different regulation. Aviation was used
> > to demonstrate that C is not going away anytime soon.
> I'm terrified if anyone is crazy enough to program avionics in C. I
> know that SpaceX uses C++ which is also terrifying, but not quite in the
> same way. Ada really is the best for this from what I can tell.
>

To supply avionics software you must have DO-178 certification. And
it has extremely strict requirements. For example, on Level-A you must
provide complete MC/DC coverage. You also can't write tests "just for
coverage". You must provide complete trace from high-level requirements
to assembler code. Avionic software is most tested in the world. Until
recent Boeing accident, there were no human casualties in aviation caused
by software malfunction since DO-178 become mandatory.

The development tools must be qualified for usage in Avionics. For C we
have a lot of instruments that help us satisfy regulation requirements: LDRA,
VectorCast, etc.

So, don't worry about C. It is safe there.

SpaceX doesn't follow any serious regulations. That just need to get
acceptance from NASA. Their approach won't work in aviation. Actually,
Tesla approach won't work in aviation too. Just imagine, that you board
Airbus and pilot shouts -- "Lady and Gentleman, we are happy to see you
on our airliner. We are currently updating board systems to latest beta
software. God save us all". Koopman writes a lot on this topic.

> I believe a lot of aerospace Ada code is generated from Matlab models,
> fwiw. I have no idea how Ada's safety features interact with that.

Matlab can generate C code. That approach is commonly used to save costs.
But generated code tend to be large and ineffective compared to handwritten.
This may change in future.

> > Ada found a niche in Safety Critical Development and stays strong there.
> > Read about SPARK: https://www.adacore.com/about-spark
> Yes I tried to build it from source some years ago and got bogged down
> in dependency issues, but I will try again sometime.

I've just downloaded prebuild software.

P.S. But we kinda moved away from Forth again.

On 23/12/2021 17:37, Nickolay Kolchin wrote:
>
> P.S. But we kinda moved away from Forth again.

Here was I thinking you and Paul were done giving reasons why
Forth was no longer suited to anything. There's more? :)

On Thursday, December 23, 2021 at 1:24:20 PM UTC+3, dxforth wrote:
> On 23/12/2021 17:37, Nickolay Kolchin wrote:
> >
> > P.S. But we kinda moved away from Forth again.
> Here was I thinking you and Paul were done giving reasons why
> Forth was no longer suited to anything. There's more? :)

I thought he was giving reasons why C is obsolete.

Imagine, if Forth has tools like LDRA and Frama-C. Will it become
acceptable for modern development?

Nickolay Kolchin schrieb am Donnerstag, 23. Dezember 2021 um 11:46:57 UTC+1:
> On Thursday, December 23, 2021 at 1:24:20 PM UTC+3, dxforth wrote:
> > On 23/12/2021 17:37, Nickolay Kolchin wrote:
> > >
> > > P.S. But we kinda moved away from Forth again.
> > Here was I thinking you and Paul were done giving reasons why
> > Forth was no longer suited to anything. There's more? :)
> I thought he was giving reasons why C is obsolete.
>
> Imagine, if Forth has tools like LDRA and Frama-C. Will it become
> acceptable for modern development?
AFAIU Frama-C builds its own abstract syntax tree from C sources.
Given that Forth is practically grammar-free, that won't work well.
BTW Frama-C itself is written in OCAML.

On Thursday, December 23, 2021 at 3:11:23 PM UTC+3, minf...@arcor.de wrote:
> Nickolay Kolchin schrieb am Donnerstag, 23. Dezember 2021 um 11:46:57 UTC+1:
> > On Thursday, December 23, 2021 at 1:24:20 PM UTC+3, dxforth wrote:
> > > On 23/12/2021 17:37, Nickolay Kolchin wrote:
> > > >
> > > > P.S. But we kinda moved away from Forth again.
> > > Here was I thinking you and Paul were done giving reasons why
> > > Forth was no longer suited to anything. There's more? :)
> > I thought he was giving reasons why C is obsolete.
> >
> > Imagine, if Forth has tools like LDRA and Frama-C. Will it become
> > acceptable for modern development?
> AFAIU Frama-C builds its own abstract syntax tree from C sources.
> Given that Forth is practically grammar-free, that won't work well.
> BTW Frama-C itself is written in OCAML.

We can perform analyse on compiled bytecode. Forth can be treated as
kind of assembler language. So, no real problem here. Also, due to simpler
language -- less things need to be checked.

Nickolay Kolchin schrieb am Donnerstag, 23. Dezember 2021 um 13:38:02 UTC+1:
> On Thursday, December 23, 2021 at 3:11:23 PM UTC+3, minf...@arcor.de wrote:
> > Nickolay Kolchin schrieb am Donnerstag, 23. Dezember 2021 um 11:46:57 UTC+1:
> > > On Thursday, December 23, 2021 at 1:24:20 PM UTC+3, dxforth wrote:
> > > > On 23/12/2021 17:37, Nickolay Kolchin wrote:
> > > > >
> > > > > P.S. But we kinda moved away from Forth again.
> > > > Here was I thinking you and Paul were done giving reasons why
> > > > Forth was no longer suited to anything. There's more? :)
> > > I thought he was giving reasons why C is obsolete.
> > >
> > > Imagine, if Forth has tools like LDRA and Frama-C. Will it become
> > > acceptable for modern development?
> > AFAIU Frama-C builds its own abstract syntax tree from C sources.
> > Given that Forth is practically grammar-free, that won't work well.
> > BTW Frama-C itself is written in OCAML.
> We can perform analyse on compiled bytecode. Forth can be treated as
> kind of assembler language. So, no real problem here. Also, due to simpler
> language -- less things need to be checked.

Are you really saying that assembly language is no real problem for certification??

Even on higher Forth level, analyse:
: TEST
POSTPONE IF ] R> ?DUP DROP ; IMMEDIATE
It compiles hassle-free in gforth ...

On Thursday, December 23, 2021 at 2:00:01 PM UTC+1, minf...@arcor.de wrote:
> Nickolay Kolchin schrieb am Donnerstag, 23. Dezember 2021 um 13:38:02 UTC+1:
> > On Thursday, December 23, 2021 at 3:11:23 PM UTC+3, minf...@arcor.de wrote:
> > > Nickolay Kolchin schrieb am Donnerstag, 23. Dezember 2021 um 11:46:57 UTC+1:
> > > > On Thursday, December 23, 2021 at 1:24:20 PM UTC+3, dxforth wrote:
> > > > > On 23/12/2021 17:37, Nickolay Kolchin wrote:
> > > > > >
> > > > > > P.S. But we kinda moved away from Forth again.
> > > > > Here was I thinking you and Paul were done giving reasons why
> > > > > Forth was no longer suited to anything. There's more? :)
> > > > I thought he was giving reasons why C is obsolete.
> > > >
> > > > Imagine, if Forth has tools like LDRA and Frama-C. Will it become
> > > > acceptable for modern development?
> > > AFAIU Frama-C builds its own abstract syntax tree from C sources.
> > > Given that Forth is practically grammar-free, that won't work well.
> > > BTW Frama-C itself is written in OCAML.
> > We can perform analyse on compiled bytecode. Forth can be treated as
> > kind of assembler language. So, no real problem here. Also, due to simpler
> > language -- less things need to be checked.
> Are you really saying that assembly language is no real problem for certification??
>
> Even on higher Forth level, analyse:
> : TEST
> POSTPONE IF ] R> ?DUP DROP ; IMMEDIATE
> It compiles hassle-free in gforth ...

How do these tools get past Goedel's second theorem?

-marcel

Nickolay Kolchin <nbkolchin@gmail.com> writes:
> Have you tried Factor?

Years ago, and I thought it was the most promising attempt to bring Forth
forward that I had ever seen.

I tried it more recently, and the build/install had become quite bloated.
The build failed in some non-obvious way, I spent a couple hours slogging
through a maze of code trying to figure out why, and then had to move on.

Andy Valencia
Home page: https://www.vsta.org/andy/
To contact me: https://www.vsta.org/contact/andy.html

On Thursday, December 23, 2021 at 4:00:01 PM UTC+3, minf...@arcor.de wrote:
> Nickolay Kolchin schrieb am Donnerstag, 23. Dezember 2021 um 13:38:02 UTC+1:
> > On Thursday, December 23, 2021 at 3:11:23 PM UTC+3, minf...@arcor.de wrote:
> > > Nickolay Kolchin schrieb am Donnerstag, 23. Dezember 2021 um 11:46:57 UTC+1:
> > > > On Thursday, December 23, 2021 at 1:24:20 PM UTC+3, dxforth wrote:
> > > > > On 23/12/2021 17:37, Nickolay Kolchin wrote:
> > > > > >
> > > > > > P.S. But we kinda moved away from Forth again.
> > > > > Here was I thinking you and Paul were done giving reasons why
> > > > > Forth was no longer suited to anything. There's more? :)
> > > > I thought he was giving reasons why C is obsolete.
> > > >
> > > > Imagine, if Forth has tools like LDRA and Frama-C. Will it become
> > > > acceptable for modern development?
> > > AFAIU Frama-C builds its own abstract syntax tree from C sources.
> > > Given that Forth is practically grammar-free, that won't work well.
> > > BTW Frama-C itself is written in OCAML.
> > We can perform analyse on compiled bytecode. Forth can be treated as
> > kind of assembler language. So, no real problem here. Also, due to simpler
> > language -- less things need to be checked.
> Are you really saying that assembly language is no real problem for certification??
>
> Even on higher Forth level, analyse:
> : TEST
> POSTPONE IF ] R> ?DUP DROP ; IMMEDIATE
> It compiles hassle-free in gforth ...

Well, this is pure theory, but:

1. We can define precondition and postcondition for each word here.
2. We are not really interested in `immediate` words verification. We are
interested in final code. But i don't see immediately how "specification"
can be written for such words. This may be an interesting challenge.
3. SPARK originally have no support for recursion and many other Ada
features. Frama-C also worked on C subset. There can be defined a
"safe" Forth wordset as a starting point.

On Thursday, December 23, 2021 at 4:06:12 PM UTC+3, Marcel Hendrix wrote:
> On Thursday, December 23, 2021 at 2:00:01 PM UTC+1, minf...@arcor.de wrote:
> > Nickolay Kolchin schrieb am Donnerstag, 23. Dezember 2021 um 13:38:02 UTC+1:
> > > On Thursday, December 23, 2021 at 3:11:23 PM UTC+3, minf...@arcor.de wrote:
> > > > Nickolay Kolchin schrieb am Donnerstag, 23. Dezember 2021 um 11:46:57 UTC+1:
> > > > > On Thursday, December 23, 2021 at 1:24:20 PM UTC+3, dxforth wrote:
> > > > > > On 23/12/2021 17:37, Nickolay Kolchin wrote:
> > > > > > >
> > > > > > > P.S. But we kinda moved away from Forth again.
> > > > > > Here was I thinking you and Paul were done giving reasons why
> > > > > > Forth was no longer suited to anything. There's more? :)
> > > > > I thought he was giving reasons why C is obsolete.
> > > > >
> > > > > Imagine, if Forth has tools like LDRA and Frama-C. Will it become
> > > > > acceptable for modern development?
> > > > AFAIU Frama-C builds its own abstract syntax tree from C sources.
> > > > Given that Forth is practically grammar-free, that won't work well.
> > > > BTW Frama-C itself is written in OCAML.
> > > We can perform analyse on compiled bytecode. Forth can be treated as
> > > kind of assembler language. So, no real problem here. Also, due to simpler
> > > language -- less things need to be checked.
> > Are you really saying that assembly language is no real problem for certification??
> >
> > Even on higher Forth level, analyse:
> > : TEST
> > POSTPONE IF ] R> ?DUP DROP ; IMMEDIATE
> > It compiles hassle-free in gforth ...
> How do these tools get past Goedel's second theorem?
>

Hoare logic?

Marcel Hendrix <mhx@iae.nl> writes:
>How do these tools get past Goedel's second theorem?

Do they? Do they need to? I don't think so. The typical way with
correctness proofs is that the programmer needs to write the program
in a way that is accepted by the prover.

- 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

среда, 22 декабря 2021 г. в 11:14:33 UTC+3, Nickolay Kolchin:
> On Wednesday, December 22, 2021 at 2:39:56 AM UTC+3, Ilya Tarasov wrote:
> > > It is a dilemma. Where are Forth's main application niches today?
> > > What is lacking in Forth that prevents it from filling these niches?
> > 1. Glueware for desktop applications.
> Doesn't Factor fills that niche?

No idea. I have no time to check every programming language in the world. For me,
Forth is a kind of programming technology and I use my own Forth translators. Factor
may be good for it's users.

On 12/22/21 22:30, Nickolay Kolchin wrote:
> On Thursday, December 23, 2021 at 7:10:16 AM UTC+3, Krishna Myneni wrote:
>> On 12/22/21 10:00, Nickolay Kolchin wrote:
>>> On Wednesday, December 22, 2021 at 6:38:16 PM UTC+3, Krishna Myneni wrote:
>>>> On 12/22/21 09:30, Nickolay Kolchin wrote:
>>>>> On Wednesday, December 22, 2021 at 5:21:40 PM UTC+3, Krishna Myneni wrote:
>>>>>> On 12/21/21 12:46, Marcel Hendrix wrote:
>>>>>>> On Tuesday, December 21, 2021 at 6:05:06 PM UTC+1, minf...@arcor.de wrote:
>>>>>>>> My impression is that there are basically three different Forth worlds:
>>>>>>>> 1) few commercially supported development toolchains with a battle-proven
>>>>>>>> vendor-specific Forth core
>>>>>>>> 2) ISO/ANS Forth with little progress and barely usable for real world apps
>>>>>>>> 3) hundreds of personal/hobby/academic Forths or VMs, often severely
>>>>>>>> crippled and unmaintained
>>>>>>>>
>>>>>>>> Ad 1) Vendors are customer-driven, they fulfill contracts. Generic language
>>>>>>>> development has no priority.
>>>>>>>>
>>>>>>>> Ad 2) and 3) There seems a tendency towards permanently reinventing
>>>>>>>> or retuning old wheels. Hence no progress there as well.
>>>>>>>>
>>>>>>>> It is a dilemma. Where are Forth's main application niches today?
>>>>>>>> What is lacking in Forth that prevents it from filling these niches?
>>>>>>>
>>>>>>> I should hope there is a fourth world where people are using
>>>>>>> Forth for their own extremely domain-specific problems.
>>>>>>> These people fully control their copy or version of Forth
>>>>>>> and have no desire to further develop the basis of an
>>>>>>> arbitrarily extensible language. The only thing they
>>>>>>> are missing (I guess) in the current time segment
>>>>>>> is the Forth Dimensions/FORML/JFAR type of
>>>>>>> papers of the past era.
>>>>>>> (https://www.forth.com/forth-books/jfar-archives/).
>>>>>>>
>>>>>>> -marcel
>>>>>>>
>>>>>> The perennial hand wringing about Forth's dim prospects for being a
>>>>>> mainstream language, even for niche applications, continues. It is a bit
>>>>>> amusing, but also a bit tiresome.
>>>>>>
>>>>>
>>>>> But 40 years ago people build complex systems in Forth. For example:
>>>>>
>>>>> http://dl.forth.com/jfar/vol3/no2/article4.pdf
>>>>>
>>>>> What has changed?
>>>>>
>>>> My guess is the availability of other, better standardized programming
>>>> languages and tools which don't depart in convention as much from
>>>> traditional procedural programming is what has changed.
>>>>
>>>
>>> Can you elaborate what do you mean by "better standardized programming
>>> languages"?
>>>
>> Upon re-reading my statement, I realize it is ambiguous with respect to
>> "better". I meant that implementations and standards for conventional
>> procedural programming had improved over the original non-Forth
>> counterparts, e.g. better standardization amongst C compilers (although
>> that may have taken a while). There were also a plethora of new
>> languages with paradigms such as OOP, e.g. C++ and Java, which retained
>> familiarity with past languages. But, perhaps the most important reason
>> that Forth was quickly overtaken was that the large software/hardware
>> companies of the early 1990s, such as Microsoft, Borland, Sun
>> Microsystems, threw their weight behind the conventional language
>> descendants. This meant, for example, they could develop large libraries
>> of ready to use components. Small Forth companies could not compete in
>> the general programming space within that environment. The above
>> observations are mostly relevant to the development of applications for
>> commercial use.
>
> Your points are valid for desktop development. But how Forth lost
> embedded?
>

Someone from an electronics engineering background may be better suited
to answer that. I have done some embedded programming on a couple of
microcontrollers, for which Forth was not available at the time. I think
C was universally available on microcontrollers at that time (mid to
late 90s). I suspect the availability of Forth on microcontrollers was
pretty limited at that time. Although engineers are usually conservative
in their implementations, I think the loss of Forth on desktop
development impacts development on embedded systems as well.

>>
>> Forth continues to evolve, as well as to fragment into variants. This
>> may be intrinsic to the nature of the language, and not altogether a bad
>> thing, unless one is only evaluating it through the lens of commercial use.
>>
>
> Can you name Forth major evolution points since ANS?
>
In my opinion, Forth 2012 was the next significant evolution point. It
cleaned up and added some missing floating point functionality (and also
standardized the separate fp stack), added standardized data structures,
standardized numeric input in different bases, added the concept of
"name token" along with a so-called higher order function which allowed
deeper introspection into the system, provided optional support for
recognizing extended characters for all words which deal with character
input and output, added a low-level parsing word which was needed, added
support for non-printable characters in strings, improved deferred word
support, and some other features.

I can't speak on the developments in the embedded world, although Forth
systems which support ARM architectures seem to be a significant
development.

Krishna

Andy Valencia schrieb am Donnerstag, 23. Dezember 2021 um 17:16:22 UTC+1:
> Nickolay Kolchin <nbko...@gmail.com> writes:
> > Have you tried Factor?
>
> Years ago, and I thought it was the most promising attempt to bring Forth
> forward that I had ever seen.
>

IMO Factor's important contribution was moving away from Forth's CPU-centricity
towards a more data-oriented design. And it 'comes' with many libraries.

On 24/12/2021 10:09, Krishna Myneni wrote:
> On 12/22/21 22:30, Nickolay Kolchin wrote:
>> ...
>> Can you name Forth major evolution points since ANS?
>>
> In my opinion, Forth 2012 was the next significant evolution point. It
> cleaned up and added some missing floating point functionality (and also
> standardized the separate fp stack), added standardized data structures,
> standardized numeric input in different bases, added the concept of
> "name token" along with a so-called higher order function which allowed
> deeper introspection into the system, provided optional support for
> recognizing extended characters for all words which deal with character
> input and output, added a low-level parsing word which was needed, added
> support for non-printable characters in strings, improved deferred word
> support, and some other features.

More consolidation of power than evolutionary as most of those pre-existed
in one form or another. The majors got their way and the independents
went theirs.

dxforth schrieb am Freitag, 24. Dezember 2021 um 01:22:11 UTC+1:
> On 24/12/2021 10:09, Krishna Myneni wrote:
> > On 12/22/21 22:30, Nickolay Kolchin wrote:
> >> ...
> >> Can you name Forth major evolution points since ANS?
> >>
> > In my opinion, Forth 2012 was the next significant evolution point. It
> > cleaned up and added some missing floating point functionality (and also
> > standardized the separate fp stack), added standardized data structures,
> > standardized numeric input in different bases, added the concept of
> > "name token" along with a so-called higher order function which allowed
> > deeper introspection into the system, provided optional support for
> > recognizing extended characters for all words which deal with character
> > input and output, added a low-level parsing word which was needed, added
> > support for non-printable characters in strings, improved deferred word
> > support, and some other features.
> More consolidation of power than evolutionary as most of those pre-existed
> in one form or another. The majors got their way and the independents
> went theirs.

It is not helpful to belittle those steps and the amount of work that went into
making the steps. A "giant leap for mankind" does not make more followers
automatically, but probably more sceptics I guess.

Nevertheless it speaks volumes to mention 'standardized data structures'
(ie BEGIN-STRUCTURE .. +FIELD .. END-STRUCTURE) as improvement in
Forth2012. This is at grass roots level, it can't get any lower. No lists, arrays,
dynamic strings etc that are elementary data types practically anywhere else.
OO with methods and classes? Google your favourite package or better
roll your own private Idaho...

On 24/12/2021 14:26, minf...@arcor.de wrote:
> dxforth schrieb am Freitag, 24. Dezember 2021 um 01:22:11 UTC+1:
>> On 24/12/2021 10:09, Krishna Myneni wrote:
>> > On 12/22/21 22:30, Nickolay Kolchin wrote:
>> >> ...
>> >> Can you name Forth major evolution points since ANS?
>> >>
>> > In my opinion, Forth 2012 was the next significant evolution point. It
>> > cleaned up and added some missing floating point functionality (and also
>> > standardized the separate fp stack), added standardized data structures,
>> > standardized numeric input in different bases, added the concept of
>> > "name token" along with a so-called higher order function which allowed
>> > deeper introspection into the system, provided optional support for
>> > recognizing extended characters for all words which deal with character
>> > input and output, added a low-level parsing word which was needed, added
>> > support for non-printable characters in strings, improved deferred word
>> > support, and some other features.
>> More consolidation of power than evolutionary as most of those pre-existed
>> in one form or another. The majors got their way and the independents
>> went theirs.
>
> It is not helpful to belittle those steps and the amount of work that went into
> making the steps.

Self-interest is hardly work.

> A "giant leap for mankind" does not make more followers
> automatically, but probably more sceptics I guess.

You say Forth lacks ready-to-use libraries. If they've not materialized
with what's been added thus far, then what, when and who?

> Nevertheless it speaks volumes to mention 'standardized data structures'
> (ie BEGIN-STRUCTURE .. +FIELD .. END-STRUCTURE) as improvement in
> Forth2012. This is at grass roots level, it can't get any lower.

You can define them yourself - if you really needed them. They mimic methods
found in other languages, despite Forth offering other possibilities which
are arguably more forth-like. Forth today smacks of 'cultural cringe'. You
could put it in the Standard and nobody would even notice :)

> No lists, arrays,
> dynamic strings etc that are elementary data types practically anywhere else.
> OO with methods and classes? Google your favourite package or better
> roll your own private Idaho...

QED

On Thursday, December 23, 2021 at 6:36:58 PM UTC+1, Anton Ertl wrote:
> Marcel Hendrix <m...@iae.nl> writes:
> >How do these tools get past Goedel's second theorem?
> Do they? Do they need to? I don't think so. The typical way with
> correctness proofs is that the programmer needs to write the program
> in a way that is accepted by the prover.

IOW, axiom one: the prover is correct?

-marcel