Re: Parsing timestamps?

Am 01.07.2025 um 23:47 schrieb peter:

On Tue, 01 Jul 2025 11:40:38 -0700
Paul Rubin <no.email@nospam.invalid> wrote:
 

Hans Bezemer <the.beez.speaks@gmail.com> writes:

But such would indicate a deficiency in Forth.  Do C programmers
reach a point at which they can't go forward? ...

Another great argument to leave Forth and embrace C! Why painfully
create kludge to cram into a language that was clearly not created
for that when you have a language available that was actually
DESIGNED with those requirements in mind?!

>
I'm not sure what you're getting at here, though I see the sarcasm.
>
Is the kludge locals?  They don't seem that kludgy to me.
Implementing them in Forth is straightforward and lots of people have
done it.
>
Finally, a fancy enough Forth compiler can do the same things that a C
compiler does.  Those compilers are difficult to write, but they exist
(VFX, lxf, etc.).  I don't know if locals make writing the compiler
more difficult.  But the user shouldn't have to care.

 The code generator in lxf has no knowledge of what a local is.
locals are conceptually placed on the return stack. lxf is as smart
about the return stack as the data stack. that is why it can produce
very efficient code for simple examples like 3DUP. The actual
implementation of local in the interpreter is just a few lines of code.
The difference with locals will be seen when you have a boundary block,
IF statement, a call etc that require a known state of the stacks.
The real problem for me with locals is that their scope is to the end
of the definition. With the stack you end the scope of an item with a
drop and extend it with a dup, very elegant!
A multipass compiler can of course find the scope of each local but at
the cost of more complexity.
 In lxf64 I have introduced a local stack with the same capabilities as
the data and return stack. I am not sure yet if this is better.
 The nice thing is that I now have >ls ls> and ls@. Compared with the
return stack this also works across words. One word can put stuff on
the localstack and another retrieve it. This is sometimes very useful.

In a sense, such locals become global. I am not sure if this opens the way inadvertently for hard-to-detect bugs. One rarely discussed property of locals is that they offer data encapsulation (or have scope in C terminology).
Only one useful application comes to my mind: sharing locals between
quotation and its parent function, i.e. for creating closures. But who needs thema anyway?