I've made casual use of Forth for decades.
I like what I see as the forth philosophy - simple & direct.
I wish to suggest changes to the installer of my preferred OS.

I went looking for statements of the "FORTH philosophy", but what I
found was too "code" rather than "project" oriented.

Examples I found include:

> Basically, a Forth programmer wants to throw out absolutely everything he
> possibly can in his program and in his programming environment except that
> which is absolutely essential for solving the problem at hand.
https://mvanier.livejournal.com/2133.html

> This keeps me true to the Forth philosophy (or at least Chuck Moore's philosophy)
> of only doing what you need to do to meet the task at hand.
http://toddbot.blogspot.com/2012/04/why-forth-still-matters-in-this.html

> ... because Forth does not start with code. It starts with simplifying things
> by questioning assumptions.
https://26thcenturyprogramming.wordpress.com/2015/03/26/the-forth-philosophy-maybe-p/

Can anyone suggest appropriate online reading?
TIA

On Thursday, March 3, 2022 at 8:07:22 AM UTC-6, Richard Owlett wrote:

> I like what I see as the forth philosophy - simple & direct.

That should do. All the rest could float a fleet of Zeplins.

--
me

On Thursday, March 3, 2022 at 3:07:22 PM UTC+1, Richard Owlett wrote:
> I've made casual use of Forth for decades.
> I like what I see as the forth philosophy - simple & direct.
> I wish to suggest changes to the installer of my preferred OS.
>
> I went looking for statements of the "FORTH philosophy", but what I
> found was too "code" rather than "project" oriented.
I'm quite amazed you chose these items. They're first impression - not the ramblings of seasoned Forth programmers. E.g.

"One other thing: even though I think Forth is way cool, it would not be my first choice for most of my programming projects. There are too many features I consider essential for most of my programming work that are missing from Forth (and are very hard to add to it). These include garbage collection, first-class functions and a type discipline".

- Type discipline?! That's almost cursing in Forths church!
- Garbage collection. There's some massive library, but I've been happy to introduce arena allocation, dynamic strings and TWO types of dynamic arrays to my own 4tH.
- First class functions. According to Wikipedia: "This means the language supports passing functions as arguments to other functions, returning them as the values from other functions, and assigning them to variables or storing them in data structures. Some programming language theorists require support for anonymous functions". Ok, which of these things can you NOT do with execution tokens..?

My answer to all this humbug has always been: https://sourceforge.net/p/forth-4th/wiki/4tH%20philosophy/

If you don't know this - you DO NOT know Forth!

BTW, I got plenty of these:
https://sourceforge.net/p/forth-4th/wiki/The%20Way%20of%20Forth/
https://sourceforge.net/p/forth-4th/wiki/This%20is%20Forth/

Some think Chucks Firechats and Jeff Fox (e.g. http://www.ultratechnology.com/forth.htm) were the best writings on Forth. To me, they contain some great ideas - but a bit too "mystical" for my taste. To me the best article written is this one by Bernd Paysan: https://bernd-paysan.de/why-forth.html

Hans Bezemer

On Thursday, March 3, 2022 at 11:18:34 AM UTC-7, the.bee...@gmail.com wrote:
> On Thursday, March 3, 2022 at 3:07:22 PM UTC+1, Richard Owlett wrote:
> > I've made casual use of Forth for decades.
> > I like what I see as the forth philosophy - simple & direct.
> > I wish to suggest changes to the installer of my preferred OS.
> >
> > I went looking for statements of the "FORTH philosophy", but what I
> > found was too "code" rather than "project" oriented.
> I'm quite amazed you chose these items. They're first impression - not the ramblings of seasoned Forth programmers. E.g.
>
> "One other thing: even though I think Forth is way cool, it would not be my first choice for most of my programming projects. There are too many features I consider essential for most of my programming work that are missing from Forth (and are very hard to add to it). These include garbage collection, first-class functions and a type discipline".
>
> - Type discipline?! That's almost cursing in Forths church!
> - Garbage collection. There's some massive library, but I've been happy to introduce arena allocation, dynamic strings and TWO types of dynamic arrays to my own 4tH.
> - First class functions. According to Wikipedia: "This means the language supports passing functions as arguments to other functions, returning them as the values from other functions, and assigning them to variables or storing them in data structures. Some programming language theorists require support for anonymous functions". Ok, which of these things can you NOT do with execution tokens..?
>
> My answer to all this humbug has always been: https://sourceforge.net/p/forth-4th/wiki/4tH%20philosophy/
>
> If you don't know this - you DO NOT know Forth!
>
> BTW, I got plenty of these:
> https://sourceforge.net/p/forth-4th/wiki/The%20Way%20of%20Forth/
> https://sourceforge.net/p/forth-4th/wiki/This%20is%20Forth/
>
> Some think Chucks Firechats and Jeff Fox (e.g. http://www.ultratechnology..com/forth.htm) were the best writings on Forth. To me, they contain some great ideas - but a bit too "mystical" for my taste. To me the best article written is this one by Bernd Paysan: https://bernd-paysan.de/why-forth.html
>
> Hans Bezemer
Why do programs generate so much garbage in the first place? Can't we be environmentally friendly?

On Thursday, March 3, 2022 at 1:18:34 PM UTC-5, the.bee...@gmail.com wrote:
> On Thursday, March 3, 2022 at 3:07:22 PM UTC+1, Richard Owlett wrote:
> > I've made casual use of Forth for decades.
> > I like what I see as the forth philosophy - simple & direct.
> > I wish to suggest changes to the installer of my preferred OS.
> >
> > I went looking for statements of the "FORTH philosophy", but what I
> > found was too "code" rather than "project" oriented.
> I'm quite amazed you chose these items. They're first impression - not the ramblings of seasoned Forth programmers. E.g.
>
> "One other thing: even though I think Forth is way cool, it would not be my first choice for most of my programming projects. There are too many features I consider essential for most of my programming work that are missing from Forth (and are very hard to add to it). These include garbage collection, first-class functions and a type discipline".
>
> - Type discipline?! That's almost cursing in Forths church!
> - Garbage collection. There's some massive library, but I've been happy to introduce arena allocation, dynamic strings and TWO types of dynamic arrays to my own 4tH.
> - First class functions. According to Wikipedia: "This means the language supports passing functions as arguments to other functions, returning them as the values from other functions, and assigning them to variables or storing them in data structures. Some programming language theorists require support for anonymous functions". Ok, which of these things can you NOT do with execution tokens..?

Returning pointers to functions or passing functions as arguments would seem to essentially be self modifying code, no?

--

Rick C.

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

On 4/03/2022 01:53, S Jack wrote:
> On Thursday, March 3, 2022 at 8:07:22 AM UTC-6, Richard Owlett wrote:
>
>> I like what I see as the forth philosophy - simple & direct.
>
> That should do. All the rest could float a fleet of Zeplins.

Except 'simple & direct' is propaganda. The word is not the experience
- no matter how many times one repeats it. The idea one can achieve the
same insights as another by copying what they do.

Rick C <gnuarm.deletethisbit@gmail.com> writes:
> Returning pointers to functions or passing functions as arguments
> would seem to essentially be self modifying code, no?

No it just means functions are values, whose implementation involves
pointers to code.

For example, sin (sine) is a function, whose input is a real and whose
output is another real. And "derivative" (d/dx) is a function whose
input is a function, and whose output is another function. So you get
that d/dx (sin) = cos, or some numerical approximation of same. In
Python or Haskell, this is easy, e.g.:

h = 0.0001
d_over_dx f = g where { g x = (f(x+h) - f(x)) / h }
dsin = d_over_dx sin
print (dsin 0.5) -- prints 0.8775585891507287
print (cos 0.5) -- prints 0.8775825618903728

Pretty close approximation. In Forth it is a bit messier because you
want a signature like

: d/dx ( xt -- xt ) .... ;

and you may have to do some advanced or non-portable things to create
new xt's on the fly like that. But there are various ways you can get
equivalent functionality using OOP or whatever.

Hans Bezemer <the.beez.speaks@gmail.com> writes:
> - Garbage collection. There's some massive library, but I've been
> happy to introduce arena allocation, dynamic strings and TWO types of
> dynamic arrays to my own 4tH.

It's not that massive: a few hundred lines of Forth.

https://www.complang.tuwien.ac.at/forth/garbage-collection.zip

It's worth reading the doc file (gc.html) inside that zip, that explains
how it works and why you might want it. Unfortunately, traditional
Forth misses a few features that prevents the gc from being completely
portable, such as a way to scan the return stack. But these are fairly
simple implementation gaps. If I ever write a Forth, I'll want it to
fully support this gc.

> My answer to all this humbug has always been:
> https://sourceforge.net/p/forth-4th/wiki/4tH%20philosophy/
>
> If you don't know this - you DO NOT know Forth!

I like some parts of that doc, but other parts are unconvincing. E.g.
string concatention:

strcat(strcat(strcat(strcpy(hello,"Hello"), " "), "world"), "!");

In Python you'd write "Hello" + " " + "world" + "!" which is simple.

Your Forth equivalent is:

include lib/concat.4th
s" Hello" s" " s" world" s" !" 4 Hello concat

That is nice, but where does the storage for the new string come from,
and do you have to remember to free it when you are done with it?
That's one more thing to occupy your mind and create bugs in your
program, that Python takes care of for you automatically.

Similarly with locals: 1) you can stack-allocate them, so not much
overhead; 2) without them, you are programming a simple stack VM in
machine language, which means you must mentally perform the register
allocation part of a traditional compiler if you don't want to spew
VARIABLEs all over.

> https://sourceforge.net/p/forth-4th/wiki/The%20Way%20of%20Forth/

I would think of possible "knight move" paths that visit all 8 cells.
It's clear that if you have 1 such path, the cyclic permutations on its
moves are also paths, so you only have to look at one starting point.
Also, the path's inverse (reverse the letters) is also a path, and after
the 6th move, there is only one possible move choice to reach the last
letter. So you only have to make 6 actual choices. So you search the
64 possible paths and find there is really only one, modulo the
symmetries mentioned above. That is sort of what you did, but the long
way around, ISTM.

> https://sourceforge.net/p/forth-4th/wiki/This%20is%20Forth/

This one just makes Forth look painful ;).

> Some think Chucks Firechats and Jeff Fox
> (e.g. http://www.ultratechnology.com/forth.htm) were the best writings

I enjoyed those a lot.

> on Forth. To me, they contain some great ideas - but a bit too
> "mystical" for my taste. To me the best article written is this one by
> Bernd Paysan: https://bernd-paysan.de/why-forth.html

I liked this for the most part, though some parts were less convincing
than others.

Paul Rubin schrieb am Freitag, 4. März 2022 um 09:41:36 UTC+1:
> Rick C <gnuarm.del...@gmail.com> writes:
> > Returning pointers to functions or passing functions as arguments
> > would seem to essentially be self modifying code, no?
> No it just means functions are values, whose implementation involves
> pointers to code.
>
> For example, sin (sine) is a function, whose input is a real and whose
> output is another real. And "derivative" (d/dx) is a function whose
> input is a function, and whose output is another function. So you get
> that d/dx (sin) = cos, or some numerical approximation of same. In
> Python or Haskell, this is easy, e.g.:
>
> h = 0.0001
> d_over_dx f = g where { g x = (f(x+h) - f(x)) / h }
> dsin = d_over_dx sin
> print (dsin 0.5) -- prints 0.8775585891507287
> print (cos 0.5) -- prints 0.8775825618903728
>
> Pretty close approximation. In Forth it is a bit messier because you
> want a signature like
>
> : d/dx ( xt -- xt ) .... ;
>
> and you may have to do some advanced or non-portable things to create
> new xt's on the fly like that. But there are various ways you can get
> equivalent functionality using OOP or whatever.

Clumsy but portable:

0.0001e FVALUE h

DEFER ofunc ' FSIN IS ofunc
DEFER dfunc

: D/DX {: xt f: x -- y :}
x h f+ xt execute x xt execute f- h f/ ;

:NONAME ( x -- y ) ['] ofunc D/DX ; IS dfunc

0.5e dfunc f.
0.5e fcos f.

On 3/4/22 4:47 AM, Paul Rubin wrote:

> In Python you'd write "Hello" + " " + "world" + "!" which is simple.

Some people, like me, believe the future of Forth may be something like
Oforth (which also has gc):

"Hello" " " + "world" + "!" +

-Doug

> Your Forth equivalent is:
>
> include lib/concat.4th
> s" Hello" s" " s" world" s" !" 4 Hello concat
>
> That is nice, but where does the storage for the new string come from,
> and do you have to remember to free it when you are done with it?
> That's one more thing to occupy your mind and create bugs in your
> program, that Python takes care of for you automatically.

The future of Forth may be something like Oforth, but I noticed there
hasn't been a release in 3.5 years, nor any signs from Franck Bensusan.

I sent him an email to see if he's ok, and the mail was rejected because
the mailbox is full.

So I hope Franck's OK...

On 2022-03-04 14:22, Doug Hoffman wrote:
> On 3/4/22 4:47 AM, Paul Rubin wrote:
>
>> In Python you'd write "Hello" + " " + "world" + "!" which is simple.
>
> Some people, like me, believe the future of Forth may be something like
> Oforth (which also has gc):
>
> "Hello" " " + "world" + "!" +
>
> -Doug
>
>
>> Your Forth equivalent is:
>>
>>      include lib/concat.4th
>>      s" Hello" s"  " s" world" s" !" 4 Hello concat
>>
>> That is nice, but where does the storage for the new string come from,
>> and do you have to remember to free it when you are done with it?
>> That's one more thing to occupy your mind and create bugs in your
>> program, that Python takes care of for you automatically.

On Friday, March 4, 2022 at 10:47:13 AM UTC+1, Paul Rubin wrote:
> Hans Bezemer <the.bee...@gmail.com> writes:
> It's not that massive: a few hundred lines of Forth.
Hmm, I thought it was an interesting thing to examine where this impression came from. So I took all of 4tH's 500+ libraries and analyzed them both "raw lines" and "source lines of code". In both cases, the vast majority (85% - 90%) popped up between "more than 4, but less than 128 LOC".

So yes, from my point of view 400 lines is MASSIVE! That's about the size of the 4tH preprocessor (which without libs is a little less than 500 lines)..

> It's worth reading the doc file (gc.html) inside that zip, that explains
> how it works and why you might want it. Unfortunately, traditional
> Forth misses a few features that prevents the gc from being completely
> portable, such as a way to scan the return stack. But these are fairly
> simple implementation gaps.
It functions IMHO about the same way uBasic/4tH's GC does. But hat one is about 50 (raw) lines. On the other hand (all raw lines of code):
- Dynamic array (sequential) is 65 lines;
- Dynamic array (random) is 45 lines;
- Dynamic strings is 30 lines;
- Arena allocation is 85 lines.

Even having ALL of these at the same time in a 4tH program doesn't amount to 400 lines. I'm not saying that GC.F is bad code - on the contrary - I'm saying it's just a LOT of code.

> > My answer to all this humbug has always been:
> > https://sourceforge.net/p/forth-4th/wiki/4tH%20philosophy/
> In Python you'd write "Hello" + " " + "world" + "!" which is simple.
My answer is always the same - what looks simple and elegant on the outside may amount to very messy and overly bloated code on the inside. IMHO - that counts. You're free to feel otherwise, of course. As long as I don't have to maintain it..
> Your Forth equivalent is:
> include lib/concat.4th
> s" Hello" s" " s" world" s" !" 4 Hello concat

No - even IF you read the article, you didn't understand it. Since I gave at least three or four variations on this theme, saying it pretends on the program and programmer to select the correct one. I'm just saying that equivalents are available - IT'S NOT FORTH THAT'S LACKING - IT'S THE SKILLS OF THE WANNABEES WHO TRY TO USE IT.
> That is nice, but where does the storage for the new string come from,
> and do you have to remember to free it when you are done with it?
> That's one more thing to occupy your mind and create bugs in your
> program, that Python takes care of for you automatically.
If you have to contemplate that - use Python. Don't pretend you're a Forth programmer. Delve into the writings of Dijkstra if you still believe this "the language will save all n00bs" myth.

> Similarly with locals: 1) you can stack-allocate them, so not much
> overhead; 2) without them, you are programming a simple stack VM in
> machine language, which means you must mentally perform the register
> allocation part of a traditional compiler if you don't want to spew
> VARIABLEs all over.
It's overhead nonetheless. IMHO locals are a horrible C-ism. I never had to resort to locals to write a lib. I MAY use them in an application, but <sigh> I got so many alternatives to that:
(1) I just may be more clever - and use the stack as it's supposed to be: https://sourceforge.net/p/forth-4th/wiki/This%20is%20Forth/
(2) I may create an additional stack (tiny bit of code): https://sourceforge.net/p/forth-4th/code/HEAD/tree/trunk/4th.src/lib/stack.4th
(3) I may use the Return Stack more cleverly: https://sourceforge.net/p/forth-4th/wiki/Using%20R%40/

And that IMHO is Forth - there is no single right way to do it. You choose your guns - you're not obliged to take a knife to a gunfight.

> I would think of possible "knight move" paths that visit all 8 cells.
> It's clear that if you have 1 such path, the cyclic permutations on its
> moves are also paths, so you only have to look at one starting point.
> Also, the path's inverse (reverse the letters) is also a path, and after
> the 6th move, there is only one possible move choice to reach the last
> letter. So you only have to make 6 actual choices. So you search the
> 64 possible paths and find there is really only one, modulo the
> symmetries mentioned above. That is sort of what you did, but the long
> way around, ISTM.
Again, you either didn't read or didn't understand the article. I used Forth as a tool to discover the algorithm. And I boiled it down to 17326045. That someone else with a different academic path would tackle the matter differently isn't the point of the article. The point is, that even if you have a difficult way to calculate the fee for a long distance calls, Forthers don't stop to investigate it until they've reached the bare essentials of the algorithm.

> This one just makes Forth look painful ;).
It SHOULD be "painful" if you want to have the best Forth implementation. See also: https://sourceforge.net/p/forth-4th/wiki/Understand%20your%20algorithm/
That IMHO is Forth. And that's why so many other code from so many other "easy to use languages" is subpar on each and every level.

> > Bernd Paysan: https://bernd-paysan.de/why-forth.html
> I liked this for the most part, though some parts were less convincing
> than others.
I leave it to Bernd to defend that one.
The truth can be hard, I know. But my father didn't raise a sissy ;-)

Hans Bezemer

On 3/4/22 8:21 AM, Ron AARON wrote:
> The future of Forth may be something like Oforth, but I noticed there
> hasn't been a release in 3.5 years, nor any signs from Franck Bensusan.

Yeah. I noticed the same.

> I sent him an email to see if he's ok, and the mail was rejected because
> the mailbox is full.
>
> So I hope Franck's OK...

He is. I heard from someone else that Franck is just too busy on his
real work and hasn't had time lately for Oforth which he considers a
hobby. Fortunately he has published the entire source for Oforth. So if
someone were knowledgeable and ambitious (not me), Oforth could still
evolve.

Maybe the future of Forth is something like 8th?

-Doug

On Friday, March 4, 2022 at 2:45:54 PM UTC+1, Doug Hoffman wrote:
> Maybe the future of Forth is something like 8th?
I second that motion!

And those who think this statement is only half true, can always use 4tH ;-)

Hans Bezemer

On 2022-03-04 15:48, Hans Bezemer wrote:
> On Friday, March 4, 2022 at 2:45:54 PM UTC+1, Doug Hoffman wrote:
>> Maybe the future of Forth is something like 8th?
> I second that motion!
>
> And those who think this statement is only half true, can always use 4tH ;-)

:)

On 2022-03-04 15:45, Doug Hoffman wrote:
> On 3/4/22 8:21 AM, Ron AARON wrote:
>> The future of Forth may be something like Oforth, but I noticed there
>> hasn't been a release in 3.5 years, nor any signs from Franck Bensusan.
>
> Yeah. I noticed the same.
>
>> I sent him an email to see if he's ok, and the mail was rejected
>> because the mailbox is full.
>>
>> So I hope Franck's OK...
>
> He is. I heard from someone else that Franck is just too busy on his
> real work and hasn't had time lately for Oforth which he considers a
> hobby. Fortunately he has published the entire source for Oforth. So if
> someone were knowledgeable and ambitious (not me), Oforth could still
> evolve.

Good he's OK, thanks for the update.

>
> Maybe the future of Forth is something like 8th?

Maybe... I'm happy either way.

On Friday, March 4, 2022 at 3:41:36 AM UTC-5, Paul Rubin wrote:
> Rick C <gnuarm.del...@gmail.com> writes:
> > Returning pointers to functions or passing functions as arguments
> > would seem to essentially be self modifying code, no?
> No it just means functions are values, whose implementation involves
> pointers to code.

Of course, but by using pointers to code to control execution is no different from modifying code. There is no way to analyze the code to verify it is written correctly.

> For example, sin (sine) is a function, whose input is a real and whose
> output is another real. And "derivative" (d/dx) is a function whose
> input is a function, and whose output is another function. So you get
> that d/dx (sin) = cos, or some numerical approximation of same. In
> Python or Haskell, this is easy, e.g.:
>
> h = 0.0001
> d_over_dx f = g where { g x = (f(x+h) - f(x)) / h }
> dsin = d_over_dx sin
> print (dsin 0.5) -- prints 0.8775585891507287
> print (cos 0.5) -- prints 0.8775825618903728
>
> Pretty close approximation. In Forth it is a bit messier because you
> want a signature like
>
> : d/dx ( xt -- xt ) .... ;
>
> and you may have to do some advanced or non-portable things to create
> new xt's on the fly like that. But there are various ways you can get
> equivalent functionality using OOP or whatever.

Sorry, I don't know Python or Haskell. But I do know that while you can construct very simple examples, it doesn't prove a point.

--

Rick C.

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

On Friday, March 4, 2022 at 5:16:59 AM UTC-5, minf...@arcor.de wrote:
> Paul Rubin schrieb am Freitag, 4. März 2022 um 09:41:36 UTC+1:
> > Rick C <gnuarm.del...@gmail.com> writes:
> > > Returning pointers to functions or passing functions as arguments
> > > would seem to essentially be self modifying code, no?
> > No it just means functions are values, whose implementation involves
> > pointers to code.
> >
> > For example, sin (sine) is a function, whose input is a real and whose
> > output is another real. And "derivative" (d/dx) is a function whose
> > input is a function, and whose output is another function. So you get
> > that d/dx (sin) = cos, or some numerical approximation of same. In
> > Python or Haskell, this is easy, e.g.:
> >
> > h = 0.0001
> > d_over_dx f = g where { g x = (f(x+h) - f(x)) / h }
> > dsin = d_over_dx sin
> > print (dsin 0.5) -- prints 0.8775585891507287
> > print (cos 0.5) -- prints 0.8775825618903728
> >
> > Pretty close approximation. In Forth it is a bit messier because you
> > want a signature like
> >
> > : d/dx ( xt -- xt ) .... ;
> >
> > and you may have to do some advanced or non-portable things to create
> > new xt's on the fly like that. But there are various ways you can get
> > equivalent functionality using OOP or whatever.
> Clumsy but portable:
>
> 0.0001e FVALUE h
>
> DEFER ofunc ' FSIN IS ofunc
> DEFER dfunc
>
> : D/DX {: xt f: x -- y :}
> x h f+ xt execute x xt execute f- h f/ ;
>
> :NONAME ( x -- y ) ['] ofunc D/DX ; IS dfunc
>
> 0.5e dfunc f.
> 0.5e fcos f.

It would seem that the use of DEFER is a perfect example of self modifying code. You literally have no idea of what function is connected to a name at run time. In fact, that is the point of DEFER, to allow the definition connected to a deferred word to be changed at will. But it makes the code unverifiable by formal methods, no?

--

Rick C.

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

On Friday, March 4, 2022 at 7:04:38 PM UTC+1, gnuarm.del...@gmail.com wrote:
> It would seem that the use of DEFER is a perfect example of self modifying code.
> You literally have no idea of what function is connected to a name at run time. In fact, that is the point of DEFER, to allow the definition connected to a deferred word to be changed at will.
> But it makes the code unverifiable by formal methods, no?
IMHO - not if you limit the number of paths that can be taken. E.g. in uBasic/4tH the DEFER .NUMBER is *only* moved from its default (NUMBER) when a USING() clause is used - and immediately reset afterwards.

Of course, if you create a situation where you have no idea what you're doing, you're doing it wrong. Therefore, I advise 4tH users to use the PROTO: / :PROTO construct when they're simply want to delay implementation - because that one allows only one single assignment - or you'll get an error thrown at you.

I must say - that one allowed me to scrap a lot of DEFERs.

Hans Bezemer

gnuarm.del...@gmail.com schrieb am Freitag, 4. März 2022 um 19:04:38 UTC+1:
> On Friday, March 4, 2022 at 5:16:59 AM UTC-5, minf...@arcor.de wrote:
> > Clumsy but portable:
> >
> > 0.0001e FVALUE h
> >
> > DEFER ofunc ' FSIN IS ofunc
> > DEFER dfunc
> >
> > : D/DX {: xt f: x -- y :}
> > x h f+ xt execute x xt execute f- h f/ ;
> >
> > :NONAME ( x -- y ) ['] ofunc D/DX ; IS dfunc
> >
> > 0.5e dfunc f.
> > 0.5e fcos f.
>
> It would seem that the use of DEFER is a perfect example of self modifying code. You literally have no idea of what function is connected to a name at run time.

There are DEFER@ and ACTION-OF ....

Hi Richard,

YMMV, but checkout http://www.ultratechnology.com/, if you didn't already.

Also from the same site, check this one specifically http://www.ultratechnology.com/method.htm

Hope it help.

regards,

Rick C <gnuarm.deletethisbit@gmail.com> writes:
> Of course, but by using pointers to code to control execution is no
> different from modifying code.

It's completely different, as in the notion of a cpu that executes code
from ROM and puts data in RAM. Modifying the code (including
self-modification) in such a cpu is impossible, but pointers to code are
just a data words.

> There is no way to analyze the code to verify it is written correctly.

It is true, programs involving pointers, including data pointers, are
harder to analyze in general. OOP including in languages like Java is
almost always implemented using code pointers and it does obscure the
control flow.

Analysis is possible but it requires careful control over how pointers
are created and used, and it's easier if there is language support for
that.

> Sorry, I don't know Python or Haskell. But I do know that while you
> can construct very simple examples, it doesn't prove a point.

In electrical engineering I'm sure you studied derivatives, integrals,
Fourier transforms, Laplace transforms, and all that. Those are all
"operators", which take a function and give you back another function.
Digital or analog filters are another example: you put in a waveform
(which is like a function) and get back another waveform.

There is a style of programming that uses functions and operators as
data in the program, and there are languages that make this easy to do.
It is well supported in Haskell and to a lesser extent in Python.

I would say that this style is not well-supported in Forth, but it is
doable with some effort. It is reasonable to say that this style is
usually not of much benefit to the types of programs that get written in
Forth. So it's ok for Forth that the support is missing.

OOP (including in languages like Java) also is usually implemented using
function pointers. You are right that it can make things confusing,
since the program's control flow is obscured.

On Friday, March 4, 2022 at 4:48:59 PM UTC-5, Paul Rubin wrote:
> Rick C <gnuarm.del...@gmail.com> writes:
> > Of course, but by using pointers to code to control execution is no
> > different from modifying code.
> It's completely different, as in the notion of a cpu that executes code
> from ROM and puts data in RAM. Modifying the code (including
> self-modification) in such a cpu is impossible, but pointers to code are
> just a data words.

You fail to even understand the concept. If a pointer to code is executed, the code executed depends on the data in a way that is equivalent to self modifying code.

> > There is no way to analyze the code to verify it is written correctly.
> It is true, programs involving pointers, including data pointers, are
> harder to analyze in general. OOP including in languages like Java is
> almost always implemented using code pointers and it does obscure the
> control flow.

Pointers to data is very different from pointers to code. Data pointers will not modify the structure of the code.

> Analysis is possible but it requires careful control over how pointers
> are created and used, and it's easier if there is language support for
> that.
> > Sorry, I don't know Python or Haskell. But I do know that while you
> > can construct very simple examples, it doesn't prove a point.
> In electrical engineering I'm sure you studied derivatives, integrals,
> Fourier transforms, Laplace transforms, and all that. Those are all
> "operators", which take a function and give you back another function.
> Digital or analog filters are another example: you put in a waveform
> (which is like a function) and get back another waveform.
>
> There is a style of programming that uses functions and operators as
> data in the program, and there are languages that make this easy to do.
> It is well supported in Haskell and to a lesser extent in Python.
>
> I would say that this style is not well-supported in Forth, but it is
> doable with some effort. It is reasonable to say that this style is
> usually not of much benefit to the types of programs that get written in
> Forth. So it's ok for Forth that the support is missing.
>
> OOP (including in languages like Java) also is usually implemented using
> function pointers. You are right that it can make things confusing,
> since the program's control flow is obscured.

--

Rick C.

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

On Friday, March 4, 2022 at 1:27:56 PM UTC-5, the.bee...@gmail.com wrote:
> On Friday, March 4, 2022 at 7:04:38 PM UTC+1, gnuarm.del...@gmail.com wrote:
> > It would seem that the use of DEFER is a perfect example of self modifying code.
> > You literally have no idea of what function is connected to a name at run time. In fact, that is the point of DEFER, to allow the definition connected to a deferred word to be changed at will.
> > But it makes the code unverifiable by formal methods, no?
> IMHO - not if you limit the number of paths that can be taken. E.g. in uBasic/4tH the DEFER .NUMBER is *only* moved from its default (NUMBER) when a USING() clause is used - and immediately reset afterwards.
>
> Of course, if you create a situation where you have no idea what you're doing, you're doing it wrong. Therefore, I advise 4tH users to use the PROTO: / :PROTO construct when they're simply want to delay implementation - because that one allows only one single assignment - or you'll get an error thrown at you.
>
> I must say - that one allowed me to scrap a lot of DEFERs.

Of course if you write perfect code, it will always work. A pointer to a function that can be changed from anywhere in the code is the same sort of problem as using GOTOs. I've never seen anything about DEFER that requires the value to be restored the way you seem to be describing.

--

Rick C.

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

Hans Bezemer <the.beez.speaks@gmail.com> writes:
> So yes, from my point of view 400 lines is MASSIVE! That's about the
> size of the 4tH preprocessor (which without libs is a little less than
> 500 lines).

How big is it compared to the total size of 4th? I looked at 4th a
while back and it was pretty big, though of course it did a lot.

I just skimmed Anton's GC and the main file (gc4image.fs) is 751 lines,
around 500 of which are not blank or comments. A lot of it is small
helper functions like "find the first nonzero bit of an array". Overall
it looks pretty understandable.

4th according to https://thebeez.home.xs4all.nl/4tH/sloc.html is 5ksloc
of C and 9ksloc of Forth, around 14k total, so 500sloc (Anton's gc) is
about 3% of that. If having a "massive" GC library as 3% of a program
simplifies or eliminates the storage management headaches of the other
97%, is that really a bad trade?

> It functions IMHO about the same way uBasic/4tH's GC does. But hat one
> is about 50 (raw) lines. On the other hand (all raw lines of code):

It sounds like you reclaim strings and arrays, but not structures
containing pointers, which requires pointer tracing. That's where the
complexity of gc comes from.

How do you know when a string is ready to be reclaimed, anyway?
Reference counting requires some kind of access convention imposed on
the whole program, another way to make mistakes unless the language
handles it.

> My answer is always the same - what looks simple and elegant on the
> outside may amount to very messy and overly bloated code on the
> inside. IMHO - that counts. You're free to feel otherwise, of
> course. As long as I don't have to maintain it..

I've written and maintained (simple) garbage collectors and it's not
that bad. Very fancy ones can be complicated, just like anything else.
I've implemented Lisp (including gc) and it's imho not harder or more
complicated than implementing Forth. The execution efficiency of a
simple implementation will be a lot worse, which might matter in some
applications, but is fine in others. It is not messy or bloated, but I
could accept that it is slow.

I've been wanting to look at this Python subset: https://sneklang.org/

> No - even IF you read the article, you didn't understand it. Since I
> gave at least three or four variations on this theme,

Yes, your complaint was that the nested strcpy in C was too hard to
read, so I picked the most readable Forth version.

> IT'S NOT FORTH THAT'S LACKING - IT'S THE SKILLS OF THE WANNABEES WHO
> TRY TO USE IT.

I think I see what you are getting at: a sufficiently skilled programmer
is able to see how to simplify string concatenation and implement the
simple-to-use version in Forth. They still have to spend effort on
that. Now imagine that string concatenation is already handled by the
language, so the skilled programmer can do something useful instead.
You get the best of both worlds ;).

> If you have to contemplate that - use Python. Don't pretend you're a
> Forth programmer. Delve into the writings of Dijkstra if you still
> believe this "the language will save all n00bs" myth.

I do use Python and have written it for a living. I use Forth for fun
sometimes, but yeah, I wouldn't call myself a Forth programmer the way
some of the regulars here are.

> [Locals] It's overhead nonetheless.

Do you mean runtime overhead? Do you really care? Is it something your
compiler can't optimize away? If the overhead matters and your compiler
can't optimize it, maybe it's better to spend the effort on the
compiler, to simplify the applications.

> IMHO locals are a horrible C-ism.

They were used in Fortran, Lisp, and Algol long before there was such a
thing as C, and (to the extent that Lisp is lambda calculus) they were
used in lambda calculus (i.e. in math) long before there was such a
thing as computers.

Have you ever used Lisp? You might give it a try sometime if you
haven't. SICP ( https://mitpress.mit.edu/sicp ) is a great book. It
uses Scheme, a very clean dialect of Lisp. The full text is online at
that site.

> And that IMHO is Forth - there is no single right way to do it. You
> choose your guns - you're not obliged to take a knife to a gunfight.

I find garbage collection to be among the most powerful of programming
"guns". Locals are not a gun, they're more like a knife, and
programming without them is like going to a knife fight with just your
fists ;).

> [Knight moves] Again, you either didn't read or didn't understand the
> article. I used Forth as a tool to discover the algorithm.

I did read the article, though maybe its point didn't reach me. Yes,
you used Forth to discover the algorithm, but it seemed to me that you
could have skipped some steps.

> The point is, that even if you have a difficult way to calculate the
> fee for a long distance calls, Forthers don't stop to investigate it
> until they've reached the bare essentials of the algorithm.

This (about not stopping to investigate), I don't understand. I would
also say someone better at algebra than I am would probably boil
explaining the knight move algorithm down to the group action of the
knight moves. I particularly don't see a way other than the brute force
search that you did, to find that there is only one solution modulo
symmetry. By analogy, the 8 queens problem on an 8x8 board has 12
solutions modulo symmetry, but I don't see how to find that out except
by enumeration.

>> This one just makes Forth look painful ;).
> It SHOULD be "painful" if you want to have the best Forth
> implementation. See also:
> https://sourceforge.net/p/forth-4th/wiki/Understand%20your%20algorithm/

I don't see what that juggling of variables onto the Forth stack has to
do with the underlying algorithm on that page. It's the same algorithm,
except that the Forth version adds pain. Think of writing assembly code
on a machine with plenty of registers, vs writing it on a machine with
just an accumulator, or on one with an AC plus an index register, etc.

They each put you through different contortions but it's the same
algorithms underneath. The idea of a HLL, I thought, was to take care
of those contortions so you don't have to. Saying "don't forget Forth's
return stack" is like saying don't forget your machine has two index
registers rather than one. Yes, that makes things easier, but sometimes
you want more than two. That's what a compiler is supposed to give you.
You code as if you had unlimited registers, and the compiler figures out
how to funnel your data through the actual machine registers. Forth
makes you do that yourself.

> The truth can be hard, I know. But my father didn't raise a sissy ;-)

Yep! Writing compilers and gc's can be hard, but tough programmers
don't back away!