Sujet : Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!]
De : no.email (at) *nospam* nospam.invalid (Paul Rubin)
Groupes : comp.lang.forthDate : 12. Sep 2024, 08:10:03
Autres entêtes
Organisation : A noiseless patient Spider
Message-ID : <8734m54ab8.fsf@nightsong.com>
References : 1 2 3 4 5 6 7 8 9
User-Agent : Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux)
Hans Bezemer <
the.beez.speaks@gmail.com> writes:
You comfortable left out the initialization of the stack
frame. Agreed, if ALL values are transferred to the return stack the
overhead is minimal. But how often happens that?
I don't understand this. {: a b c :} transfers 3 elements from the
parameter stack to the return stack. That has some cost, but it is
offset by avoiding some DUP and similar operations. Is it relevant at
all anyway? Old fashioned Forth interpreters are pretty fast, and if
you're worrying about avoiding a stack transfer here or there, you need
an optimizing compiler.
Adding safety checks has a cost, but once the program appears debugged,
I think Forth philosophy is to turn off the checks.
True - but that's not the level of abstraction I'm considering. I
think a language should have a well designed core, surrounded by a
constellation of extensions. Like C with its standard library and
Forth with its word sets.
You might like Lua or Scheme for simple higher level languages with that
style of design. C has some warts but its complexity in terms of
keywords doesn't seem much worse than Forth's core words.