From: the.beez.speaks@gmail.com
On 25-06-2025 09:21, Paul Rubin wrote:
> Hans Bezemer writes:
>> Fundamentally. I explained the sensation at the end
>> of "Why Choose Forth". I've been able to tackle things I would never
>> have been to tackle with a C mindset. ( https://youtu.be/MXKZPGzlx14 )
>
> I just watched this video and enjoyed it, but I don't understand how a C
> mindset is different. In C you pass stuff as function parameters
> instead of on the stack: what's the big deal? And particularly, the
> video said nothing about the burning question of locals ;).
>
> It seems to me all the examples mentioned in the video (parsing CSV
> files or floating point numerals) are what someone called
> micro-problems. Today they much easier with languages like Python, and
> back in Forth's heyday there was Lisp, which occupied a mindspace like
> Python does now.
>
> I agree that Thinking Forth is a great book.
It's hard to illustrate things with a multi-KLOC program IMHO. You can
only illustrate principles by using examples that are "contained" in a way.
But I'll try to illustrate a thing or two. Let's say you want to tackle
a problem. And it doesn't go your way. You have to add this thing and
that thing - and hold on to that value. You know what I mean.
When using C, you just add another local. Even *WITHIN* the loop you're
about to add. Take a look at getopt() - I think that's a good example.
You can almost see how it grew almost organically by the authors hand.
He never seemed to think "Hmm, maybe I'll make a separate function of it".
And when you take a good look, you will see how hard that is. There are
THREE globals (okay, one static) to take care of, two locals and three
parameters. So - if you want to split things off, you might have to pass
a lot of stuff - bonus points if they have to be altered.
You will reach that point in Forth *MUCH* earlier. And you cannot
(easily) create a subroutine that takes a lot of parameters and handles
them elegantly. Bonus points if you have to transfer stuff from the
Return Stack as well.
So - you'll have to use a different approach: what is the minimal thing
that can handle the majority of the functionality required. Now, how can
I extend that. Can I make some stuff local in another word so I don't
have to carry it around. Can I elegantly integrate it in my main word?
That was wrong - step back. Where did I go wrong and how can I fix it.
All these things you never ask yourself when doing C - BECAUSE YOU DON'T
HAVE TO. Everything is conveniently random accessible. You don't have to
"clean up" since every local is "auto". That's why you often see
sequences like "R> DROP R> DROP DROP NIP R> ROT" at the end of a word
(exaggerated, but still) ;-)
There is no price to pay if you pull in more resources. You don't have
to ask yourself difficult questions and you don't have to do the
(mental) work (both short-term and long term).
It's at best intellectually lazy and at worst incompetent. It's these
people who give Forth a bad name - BECAUSE WHAT THEY'RE WRITING IS AN
ABOMINATION OF FORTH.
It's an imitation. It's not real Forth. It's not a true reflection of
what Forth can do. If I can write out the C code that was most obvious
the basis of it without careful thought, it can't be Forth. It's as
simple as that.
Hans Bezemer
float array a
float array b
float array c
float array y
: tamura-kanada ( n -- fpi )
>r 1 s>f a f!
1 s>f 2 s>f fsqrt f/ b f!
1 s>f 4 s>f f/ c f!
1 s>f
r> 1 do
a f@ fdup y f!
b f@ f+ 2 s>f f/ a f!
b f@ y f@ f* fsqrt b f!
c f@ fover a f@ y f@ f-
fdup f* f* f- c f! 2 s>f f*
loop
fdrop
a f@ b f@ f+ fdup f* 4 s>f c f@ f* f/
5 n = 4
10 a = 1.0
20 b = 1/SQR(2)
30 c = 0.25
40 d = 1.0
50 FOR x = 1 TO n
60 y = a
70 a = (b+a)/2
80 b = SQR(b*y)
90 c = c - (d*(a - y)^2)
100 d = d*2
110 NEXT x
120 PRINT ((a + b)^2)/(4*c)
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
