Re: Parsing timestamps?

On 25-06-2025 09:21, Paul Rubin wrote:

Hans Bezemer <the.beez.speaks@gmail.com> 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)