Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!]

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

What bothers me most technologically is that parameters flow through
the stack undisturbed. You break that paradigm when using locals. With
locals you *HAVE TO* create some kind of stack frame that you have to
destroy when you exit.

Forth programs very frequently end up juggling parameters and other data
to and from the return stack, instead of using locals.  Simple
implementations of locals put them in the return stack too.
"Destroying" the stack frame just means adjusting RP when the function
exits.  Usually a single instruction.

Needless to say this copying, releasing and stuff takes time.

Similar to DUP (copy) or DROP (release).

In all honesty I must state that this overhead is not always
translated to a diminished performance

Right, I don't think one can assert a performance hit without
measurements supporting the idea.

TL;DR my objections are mostly based on pure architectural arguments,
rather than practicality.

Sure, that's reasonable, it's a matter of what you prefer.  That's
harder to take issue with than claims about performance.

I also don't like Python, PHP and Perl for those very same reasons -

Those are at a totally different level than Forth, in terms of layers of
implementation and runtime libraries, overhead, etc.  It's better to
compare to something like C, or a hypothetical cleaned up version of C,
or even to Forth with locals ;).