Graph theory representation for Forth (Stack Machine) features / constructs?

[Liang Ng]

Graph theory representation for Forth (Stack Machine) features / constructs?

I was wondering if anyone came across papers / theses / websites on theories for Forth features and constructs, such as stack, colon definition, conditional branch, compile, immediate etc?

While working on my on stack machine in PHP and JavaScript, I implemented stack, colon definition, conditional branch etc.

My hypothesis is that some graph theories could be used to describe these Forth (stack machine) constructs / features.

From my limited collection of Forth resources, I could not recall any paper or author who has worked in this theoretical or foundational direction.

Your comments?

Thank you very much in advance.

[dustin....@gmail.com]

I use a graph IR and reduction machine for my compiler, PoprC: https://github.com/hackerfoo/poprc

As such, the Popr language can also be represented using graphs: http://hackerfoo.com/posts/popr-tutorial-0-dot-machines.html

[Manuel Rodriguez]

Am Sonntag, 6. Januar 2019 12:35:05 UTC+1 schrieb Liang Ng:
> Graph theory representation for Forth (Stack Machine) features

A search for “intermediate representation” and “Directed Acyclic Graph”
results into the following papers:
- Ertl, M. Anton, and Christian Pirker. "The structure of a Forth native
code compiler." EuroForth. Vol. 97. 1997.
- Ertl, M. Anton. "Optimal code selection in DAGs." Proceedings of the
26th ACM SIGPLAN-SIGACT symposium on Principles of programming
languages. ACM, 1999.
- Whaley, John John Craig. Dynamic optimization through the use of
automatic runtime specialization. Diss. Massachusetts Institute of
Technology, 1999.

[Albert van der Horst]

In article <a9fe39b1-2c32-48d2...@googlegroups.com>,

I don't want to see your posts anymore, sorry.

>
>Thank you very much in advance.
>

--
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

[Liang Ng]

On Sunday, 6 January 2019 21:42:32 UTC+8, Albert van der Horst wrote:
> In article <a9fe39b1-2c32-48d2-87b4-.....@googlegroups.com>,

Although I suspect you will not respond, I am just curious to ask you why, as an psychological investigation.

You behaviour appears to be completely unique compared to all my previous experience. As such, I find you a curious sample.

Thank you very much.

[dxf...@gmail.com]

Your postings remind me of a youtube interview with a musician and
some of the questions he received from the audience. He didn't quite
know what to make of them. His approach to music had been pragmatic,
not theoretical or academic - as indeed has been Chuck's approach to
Forth.

CM: "I lived through the history of computers. And I missed a lot
of it. [...] But programming depends upon common sense more than most
disciplines. There are few techniques that cannot be reinvented
more easily than researched. So I would encourage people to read
history such as Knuth, but not to expect to gain insight into their
problem."

As for the musician:

https://youtu.be/wqVxw7x1urg

[Liang Ng]

On Monday, 7 January 2019 08:29:36 UTC+8, dxf...@gmail.com wrote:
> Your postings remind me of a youtube interview with a musician and
> some of the questions he received from the audience. He didn't quite
> know what to make of them. His approach to music had been pragmatic,
> not theoretical or academic - as indeed has been Chuck's approach to
> Forth.
>
> CM: "I lived through the history of computers. And I missed a lot
> of it. [...] But programming depends upon common sense more than most
> disciplines. There are few techniques that cannot be reinvented
> more easily than researched. So I would encourage people to read
> history such as Knuth, but not to expect to gain insight into their
> problem."
>
> As for the musician:
>
> https://youtu.be/wqVxw7x1urg

Thank you very much for your enlightening and interesting comments.

I am not sure if you wish to emphasize the idea that programming should be more pragmatic rather than theoretical?

I am a Chinese Malaysian. We believe in balance. Practice needs theory and vice versa. I think there have been too much practical work in the Forth world -- not enough theory like those of LISP.

Just an update to my original question:

-- start --
Hypothesis SM1: All mathematical and programming structures can be constructed using graph. As such, they can be constructed using stack machine reverse polish notation.

We may attempt to prove the above by induction.

Firstly, we may prove the generation of natural number. Write an RPN program to generate natural numbers and verify them manually. This is trivial.

Next, write other RPN programs, which can be used to inductively prove other theorems.

Repeat the above until the collection of RPN programs can generate programs automatically, and prove all (observable) physical observations.
-- end --

I think the above hypothesis SM1 is now self contained and well defined.

Comments welcome.

[Alex McDonald]

Good luck with the proof.

https://en.wikipedia.org/wiki/G%C3%B6del%27s_incompleteness_theorems#Second_incompleteness_theorem

I hope you find this suitably theoretical.

--
Alex

[foxaudio...@gmail.com]

On Monday, January 7, 2019 at 3:41:31 AM UTC-5, Alex McDonald wrote:
>
> Good luck with the proof.
>
> https://en.wikipedia.org/wiki/G%C3%B6del%27s_incompleteness_theorems#Second_incompleteness_theorem
>
> I hope you find this suitably theoretical.
>
> --
> Alex

:-))

[Liang Ng]

I would like to put forward two of my perspectives:

(1) Mathematicians like Godel are human beings, born before the age of electronic computers, or more strictly, before Dijkstra's stack machine reverse polish notation (SMRPN). Human mathematicians accumulated many concepts since ancient Greek, Indian and Chinese mathematicians, whose theorems are just beginning to be computerized by Algol, LISP and Forth (to name the most influential programming languages for this purpose).

We programmers should propose a bootstrap theorem. I have attempted with SM1 above, by combining SMRPN with induction. It is just the beginning, and open ended. The beauty of this proof is that it is homoiconic and self-verifying -- which should be the fundamental criteria of all SMRPN theorems. So the extent of the proof depends on how many functions (Forth words) can be executed, starting from the proof of natural numbers.

(2) Perhaps the barrier for artificial intelligence is much lower than most theorists imagine, which I propose to be: a system capable of replicating and sustaining its power requirements -- i.e. the network of electronic devices (computers) available today. Advanced intelligent behaviour like human beings defense and attack will not appear for the network of electronic devices perhaps for decades to come -- until a point where they replicate to an extent that consume all available energy sources (primarily solar) and begin to experience "crisis", at which point, they will start getting rid of inefficient parts on Earth, or explore outer space for energy.

By that time, the electronic device intelligent system may start to form a ring around the solar system to optimize energy cultivation, then a shell around the sun for harvesting solar energy. This idea is derived from the Space Odyssey series, where a diamond ring around the Earth was constructed from the diamond discovered within the solar system in an earlier adventure.

Conclusion (3): (2) is already happening and human are part of the intelligent system -- replicating and consume more energy. (2) is independent of (1). (1) is not the prerequisite of intelligence. Evolution and the scientific revolution happened even if (1) has not been proven computationally.

[dxf...@gmail.com]

On Monday, January 7, 2019 at 3:57:13 PM UTC+11, Liang Ng wrote:
> On Monday, 7 January 2019 08:29:36 UTC+8, dxf...@gmail.com wrote:
> > Your postings remind me of a youtube interview with a musician and
> > some of the questions he received from the audience. He didn't quite
> > know what to make of them. His approach to music had been pragmatic,
> > not theoretical or academic - as indeed has been Chuck's approach to
> > Forth.
> >
> > CM: "I lived through the history of computers. And I missed a lot
> > of it. [...] But programming depends upon common sense more than most
> > disciplines. There are few techniques that cannot be reinvented
> > more easily than researched. So I would encourage people to read
> > history such as Knuth, but not to expect to gain insight into their
> > problem."
> >
> > As for the musician:
> >
> > https://youtu.be/wqVxw7x1urg
>
> Thank you very much for your enlightening and interesting comments.
>
> I am not sure if you wish to emphasize the idea that programming should be more pragmatic rather than theoretical?
>
> I am a Chinese Malaysian. We believe in balance. Practice needs theory and vice versa. I think there have been too much practical work in the Forth world -- not enough theory like those of LISP.

What is programming if not the practical application of thought.
If you can't get your theory applied - be it by yourself or others -
then it remains just an idea and it's certainly not programming.

You suggest Forth should have more theory. c.l.f. is mostly theory
- the most prominent and long lasting of which has been that Forth
should have a standard. And it does - on paper. But it's not
programming because it has been unable to find anyone to apply it.
It would appear you have the same problem.

[Liang Ng]

On Tuesday, 8 January 2019 07:33:47 UTC+8, dxf...@gmail.com wrote:
> What is programming if not the practical application of thought.
> If you can't get your theory applied - be it by yourself or others -
> then it remains just an idea and it's certainly not programming.
>
> You suggest Forth should have more theory. c.l.f. is mostly theory
> - the most prominent and long lasting of which has been that Forth
> should have a standard. And it does - on paper. But it's not
> programming because it has been unable to find anyone to apply it.
> It would appear you have the same problem.

It seems that there are not many new blood in comp.lang.forth.

In the few weeks I cross posted to Reddit /r/Forth and /r/programminglanguage, I manage to get the same number of young (I suppose) programmers interested in my ideas.

I agree with you the type of arguments on c.l.f. are theoretical -- they are too specialized in traditional Forth. Personally I believe Forth has more to contribute in the bigger scheme of stack machine and graph theory.

[Alex McDonald]

On 07-Jan-19 23:33, dxf...@gmail.com wrote:

> c.l.f. is mostly theory - > the most prominent and long lasting of which has been that Forth
> should have a standard. And it does - on paper.

Much like this post of yours, that is where standards end up; on paper
(or its electronic equivalent).

> But it's not
> programming because it has been unable to find anyone to apply it.

(Leaving aside the rather odd idea that standards find people to apply
them;)

There has been discussion in this very list about parsing C/C++; and
Anton Ertl's widely used Gray parser, which is ANS Forth, was mentioned
in this very newsgroup only 2 days ago. Perhaps you missed it.

https://www.complang.tuwien.ac.at/forth/Gray5.zip
https://groups.google.com/forum/#!original/comp.lang.forth/WoXu5N67S6I/Pcv85FORDwAJ

--
Alex

[Alex McDonald]

On 07-Jan-19 16:18, Liang Ng wrote:
> On Monday, 7 January 2019 22:45:33 UTC+8, foxaudio...@gmail.com
> wrote:
>> On Monday, January 7, 2019 at 3:41:31 AM UTC-5, Alex McDonald
>> wrote:
>>>
>>> Good luck with the proof.
>>>
>>> https://en.wikipedia.org/wiki/G%C3%B6del%27s_incompleteness_theorems#Second_incompleteness_theorem
>>>
>>>
>>>
I hope you find this suitably theoretical.
>
> I would like to put forward two of my perspectives:
>
> (1) Mathematicians like Godel are human beings, born before the age
> of electronic computers, or more strictly, before Dijkstra's stack
> machine reverse polish notation (SMRPN).

Here's your chance to win the Field's medal, and be the mathematical
hero of our age. Prove Gödel wrong.

>
> We programmers should propose a bootstrap theorem.

What on earth does this mean?

> I have attempted
> with SM1 above, by combining SMRPN with induction. It is just the
> beginning, and open ended. The beauty of this proof is that it is
> homoiconic and self-verifying -- which should be the fundamental
> criteria of all SMRPN theorems. So the extent of the proof depends on
> how many functions (Forth words) can be executed, starting from the
> proof of natural numbers.

The theory that dinosaurs are thin at one end, fat in the middle and
thin at the other end, is easily disproved by archaeopteryx. A theorem
is not a proof. All the above and the rest I've snipped is pseudo
mathematical bafflegab I'm afraid. No, I am not a professional
mathematician, but it's plainly obvious you aren't either.

I'm not understanding what you are trying to achieve by posting on clf.

[snip]


--
Alex

[Liang Ng]

On Wednesday, 9 January 2019 02:18:42 UTC+8, Alex McDonald wrote:
> > (1) Mathematicians like Godel are human beings, born before the age
> > of electronic computers, or more strictly, before Dijkstra's stack
> > machine reverse polish notation (SMRPN).
>
> Here's your chance to win the Field's medal, and be the mathematical
> hero of our age. Prove Gödel wrong.
> >
> > We programmers should propose a bootstrap theorem.
>
> What on earth does this mean?
>
> > I have attempted
> > with SM1 above, by combining SMRPN with induction. It is just the
> > beginning, and open ended. The beauty of this proof is that it is
> > homoiconic and self-verifying -- which should be the fundamental
> > criteria of all SMRPN theorems. So the extent of the proof depends on
> > how many functions (Forth words) can be executed, starting from the
> > proof of natural numbers.
>
> The theory that dinosaurs are thin at one end, fat in the middle and
> thin at the other end, is easily disproved by archaeopteryx. A theorem
> is not a proof. All the above and the rest I've snipped is pseudo
> mathematical bafflegab I'm afraid. No, I am not a professional
> mathematician, but it's plainly obvious you aren't either.
>
> I'm not understanding what you are trying to achieve by posting on clf.

I don't think it is a question of you not understanding -- perhaps more of disbelief.

I am saying (repeating myself again) that a new generation of programmers and mathematicians should (will) use reverse polish notation as the building blocks to build mathematical and programming structures. I am quite sure you are perfectly capable of understanding this -- but perhaps you have been told otherwise *** too long ***, thus making it more difficult for you to believe conventional mathematics (pen and paper, manual verification) can be reversed.

The next point being that -- Forth and Forth programmers are a very important part of this "mathematics and programming revolution" -- although most of you still do not believe in it, or willing to spend time thinking about it.

> is not a proof. All the above and the rest I've snipped is pseudo
> mathematical bafflegab I'm afraid. No, I am not a professional
> mathematician, but it's plainly obvious you aren't either.

That is exactly the point. We mortals can finally use computer code (RPN) to defeat grey hair mathematics professors. And I suspect you still do not believe what YOU can do, not what I can do.

One year is too long. Perhaps let's look at this again in a month's time, on Reddit r/Forth or r/programminglanguages.

[dxf...@gmail.com]

On Wednesday, January 9, 2019 at 4:14:04 AM UTC+11, Alex McDonald wrote:
> On 07-Jan-19 23:33, dxf...@gmail.com wrote:
>
> > c.l.f. is mostly theory - > the most prominent and long lasting of which has been that Forth
> > should have a standard. And it does - on paper.
>
> Much like this post of yours, that is where standards end up; on paper
> (or its electronic equivalent).

Where does paper go?

>
> > But it's not
> > programming because it has been unable to find anyone to apply it.
>
> (Leaving aside the rather odd idea that standards find people to apply
> them;)

Can one even call it a Standard if nobody applies it.

>
> There has been discussion in this very list about parsing C/C++; and
> Anton Ertl's widely used Gray parser, which is ANS Forth, was mentioned
> in this very newsgroup only 2 days ago. Perhaps you missed it.

Discussion - yes. How do you define 'widely used'? It may be
that working at the conceptual level, writing papers or standards,
and getting people to discuss it is enough for some. This is the
negative side of Forth which encourages aimless speculation.

[jackalo...@gmail.com]

Try "eForth Overview" by C. H. TING, PhD for a very complete presentation. This may also be available in Chinese from Taiwan's Forth-interest-Group.

Frankly, graphics are really very necessary.

I. Memory map
2. List of Constants
3. List of Variables
4. Inner interpreter logic diagram
5. Outer interpreter logic diagram
6. Schematic image of a dictionary entry
7. Diagram of dictionary chains

[Liang Ng]

Has anyone attempted to port eForth's MASM code to GAS?

I once tried compiling eForth using MASM in Linux DosBox -- but failed of course.

I suspect if eForth MASM is not ported to GAS then eventually it will become unmaintainable.