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

 Name                    Last modified      Size  Description
 Parent Directory                             -   
 quit                    24-Feb-2005 18:55  4.2K