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:
.
).
-
).
!
(store, see 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).
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).