Re: Parsing timestamps?

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.
 
The point where one can't go forward is basically "running out of
registers".  In assembly language those are the machine registers, and
in Forth they're the top few stack slots.  In both cases, when you run
out, you have to resort to contorted code.
 
In C that isn't a problem for the programmer.  You can use as many
variables as you like, and if the compiler runs out of registers and
has to make contorted assembly code, it does so without your having
to care.
 
In a traditional Forth with locals, the locals are stack allocated so
accessing them usually costs a memory reference.  The programmer gets
the same convenience as a C programmer.  The runtime takes a slowdown
compared to code from a register-allocating compiler, but such a
slowdown is already present in a threaded interpreter, so it's fine.
 
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.

BR
Peter