www.delorie.com/gnu/docs/gforth/gforth_26.html

search

	Buy GNU books!

Gforth Manual

3.14 Designing the stack effect

In other languages you can use an arbitrary order of parameters for a function; and since there is only one result, you don't have to deal with the order of results, either.

In Forth (and other stack-based languages, e.g., Postscript) the parameter and result order of a definition is important and should be designed well. The general guideline is to design the stack effect such that the word is simple to use in most cases, even if that complicates the implementation of the word. Some concrete rules are:

• Words consume all of their parameters (e.g., .).

• If there is a convention on the order of parameters (e.g., from mathematics or another programming language), stick with it (e.g., -).

• If one parameter usually requires only a short computation (e.g., it is a constant), pass it on the top of the stack. Conversely, parameters that usually require a long sequence of code to compute should be passed as the bottom (i.e., first) parameter. This makes the code easier to read, because reader does not need to keep track of the bottom item through a long sequence of code (or, alternatively, through stack manipulations). E.g., ! (store, see section 5.7 Memory) expects the address on top of the stack because it is usually simpler to compute than the stored value (often the address is just a variable).

• Similarly, results that are usually consumed quickly should be returned on the top of stack, whereas a result that is often used in long computations should be passed as bottom result. E.g., the file words like open-file return the error code on the top of stack, because it is usually consumed quickly by throw; moreover, the error code has to be checked before doing anything with the other results.

These rules are just general guidelines, don't lose sight of the overall goal to make the words easy to use. E.g., if the convention rule conflicts with the computation-length rule, you might decide in favour of the convention if the word will be used rarely, and in favour of the computation-length rule if the word will be used frequently (because with frequent use the cost of breaking the computation-length rule would be quite high, and frequent use makes it easier to remember an unconventional order).