Forth Programming Style
These are some style issues in Forth programming that I felt strongly
enough about to write about. These notes are in no way exhaustive,
nor do they represent a basic style guide (for something in that
direction, read, e.g., Paul Bennet's Forth
Coding Rules). As you can see by the many Don'ts below,
I focus on specific mistakes; but I do suggest better alternatives.
- Don't use
LOCALS| this read can
you |
. Use { you can read this
}
instead.
- Don't use
EVALUATE
for macros (nor in most other applications), because it uses the
context (STATE, BASE, search order, dictionary contents, etc.) when
EVALUATE runs, not from the place where the source code is written.
Use POSTPONE-based macros or plain colon definitions instead.
- Don't write parsing words! It is hard to pass computed arguments
to them, and they lead to trouble like STATE-smartness. Instead,
words should take their arguments from the stack. If you can't resist
writing a parsing word, you can then build the parsing word as a front
end to the non-parsing word.
- Don't use
STATE
! For optimization, leave it to the Forth
system (or define two words: one for inlining and one for interactive
execution). For parsing words, provide non-parsing variants instead.
- Don't use QUIT! Just leave the word in the
ordinary way (via
;
or EXIT
), or via
THROW
.
Anton Ertl
Apache/2.4.62 (Debian) OpenSSL/3.0.15 Server at www.complang.tuwien.ac.at Port 80