Re: Parsing timestamps?

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.