In indirect threading, such as is found in FIG-Forth [Rag80,Tin89b] and numerous other Forths [Dun85,Dun86,Tin86], the execution token is the address of the code field address. The parameter field address is typically the execution token plus one cell. These considerations make alteration of the code field address more practical than alteration of the parameter field address. A difficulty arises because the parameter field address is derived implicitly from the execution token, making it onerous to associate a separate parameter field with each new binding. If access to the source code for the Forth system compiler and inner interpreter is available, the implementer can change the implementation so that the parameter field is indirectly addressed like the code field.
Lacking this, all words that are intended to be rebound in a dream could be declared with special defining words, or these words could be given the names normally reserved for their nonrebindable counterparts. This last approach is only partially acceptable, because it does not permit rebinding any of the words that are already present in the kernel. This may be circumvented, albeit clumsily, by redefining each of these kernel words with the new defining words. This produces a new set of words with the same names and actions as the originals, except that they are repackaged to permit rebinding in a dream. Nonetheless, words that were compiled before the repackaging will not exhibit the expected altered behavior if they are pondered in a dream, since they were early bound when the kernel was compiled. The major disadvantage of such an approach is that extra overhead has been added to each and every word in the application.